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Abstract 


Process  innovation  pertains  to  making  dramatic  improvements  in  performance  of 
enterprise  processes.  Stemming  from  total  quality  management,  business  process 
reengineering  and  other  widely-accepted  approaches  to  performance  improvement  in  the 
business  enterprise,  process  innovation  has  largely  been  practiced  without  a  systematic 
method  and  required  expertise  only  possessed  by  a  few,  highly-talented  people.  Now,  as 
the  result  of  research  in  this  area,  the  process  of  process  innovation  now  has  a  systematic 
method  that  helps  ensure  consistent  and  thorough  analysis,  and  through  measurement- 
driven  reasoning,  an  automated  tool  now  exists  to  enable  the  relative  amateur  to  innovate 
enterprise  processes  as  well  as  the  professional.  Moreover,  process  innovation  is  no 
longer  the  exclusive  domain  of  business  enterprises,  as  military,  governmental  and  other 
organizational  processes  can  be  innovated  with  equivalent  efficacy  using  the  method  and 
tool  described  in  this  book.  In  particular,  the  contracting  process  lends  itself  to  process 
innovation  and  is  addressed  explicitly  in  this  book. 


Foreword 


Acquisition  is  increasingly  important  in  the  Government  and  private  industry 
alike.  Past  and  present  Defense  Secretaries  have  challenged  the  acquisition  workforce  to 
effect  a  50%  reduction  in  the  cycle  time  required  to  develop  and  field  major  weapons 
systems  and  acknowledged  that  acquisition  (especially  procurement  and  logistics)  now 
limits  battlefield  information,  mobility  and  speed.  As  we  enter  the  new  millennium,  the 
"tooth  vs.  tail"  argument  no  longer  holds;  that  is,  even  military  "tail"  processes  such  as 
procurement  and  contracting  have  become  critical  success  factors  for  the  "teeth"  (e.g., 
warfighting  units).  However,  contracting  and  other  acquisition  processes  are  in  dire  need 
of  innovation.  This  book  addresses  radical  change  for  acquisition  through  process 
innovation,  with  particular  emphasis  on  the  contracting  process,  and  it  examines  in  detail 
one  high-leverage  approach  to  innovating  the  contracting  process:  alpha  contracting. 

The  "traditional"  contracting  process  is  very  common  and  quite  flawed.  It 
generally  begins  with  preparation  of  a  statement  of  work  and  proceeds  through  contract 
negotiation  to  award.  A  key  point  pertaining  to  this  "traditional"  or  baseline  process  is, 
nearly  all  activities  are  performed  either  by  the  Government  or  contractor,  but  not  both.  In 
contrast,  the  alpha  contracting  process  involves  many  activities  performed  jointly  by  the 
Government  and  contractor  teams.  This  process  innovation  offers  a  number  of  advantages 
and  performance  enhancements,  such  as  improving  communications,  decreasing  the 
number  of  formal  RFP  iterations,  revisions  and  rework  required  to  correct 
misunderstandings,  errors  and  mistakes,  reducing  the  cycle  time  (procurement 
administrative  lead  time  or  PALT)  required  for  contracting  and  others.  But  performance 
improvement  does  not  have  to  stop  with  alpha  contracting.  The  central  premise  of  this 
book  is  that  an  already-innovative  process  such  as  alpha  contracting  can  be  further 
innovated  through  systematic  process  redesign,  which  involves  reengineering  and 
managing  radical  change. 

Nearly  all  large  U.S.  corporations  have  engaged  in  major  reengineering  projects, 
and  the  Government,  including  many  military  commands,  is  also  deeply  involved  in 
reengineering  today.  Business  process  reengineering  (BPR)  builds  on  good  principles  set 
forth  through  Total  Quality  Management  (TQM),  but  it  differs  fundamentally.  For 
instance,  whereas  TQM  stresses  continuous,  incremental  process  improvements,  the 
emphasis  of  BPR  is  on  dramatic,  order-of-magnitude  leaps  in  process  performance, 
achieved  through  radical  process  redesign.  The  primary  reason  most  firms  reengineer  is 
either  to  keep  up  with  performance  improvements  effected  at  rival  firms  to  attain 
competitive  advantages  of  their  own.  But  the  military  and  government  also  have  a  great 
need  for  BPR-level  performance  and  efficiency  gains  to  offset  the  effects  of  downsizing. 

Using  a  systematic,  measurement-driven  approach  to  process  redesign,  this  book 
explains  in  considerable  detail  how  process  innovation  can  be  effected  for  a  variety  of 
processes,  and  it  specifically  targets  the  contracting  process  for  such  innovation.  The 
discussion  draws  from  experience  with  very  successful  alpha  contracting  processes  (e.g., 
as  practiced  on  the  Joint  Standoff  Weapon  (JSOW)  system)  to  demonstrate  both 
application  of  measurement-driven  process  redesign  and  illustrate  how  further  innovation 
is  possible.  After  providing  the  necessary  background  information  in  the  first  three 
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chapters — discussing  acquisition  criticality,  alpha  contracting  and  process  innovation — 
the  JSOW  alpha  contracting  process  is  modeled  for  redesign  analysis,  measured  to 
diagnose  pathologies  and  redesigned  to  further  improve  performance.  Measurements 
reveal  a  number  of  serious  pathologies  with  the  alpha  contracting  process,  which  have 
adverse  implications  in  terms  of  both  cost  and  cycle  time.  Based  on  these  diagnosed 
pathologies,  several  classes  of  redesigns  are  examined.  Both  individually  and  in 
combination,  these  process  redesigns  offer  good  potential  for  dramatic  performance 
improvement,  in  terms  of  reduced  cost  and  cycle  time.  We  also  examine  the  use  of 
advanced  information  technology  to  construct  a  vision  of  the  future  of  procurement.  Such 
a  vision  is  important  to  guide  research  and  represents  a  goal  toward  which  contract 
managers  should  strive. 

This  book  is  written  for  a  relatively  broad  audience  of  acquisition  executives,  policy 
makers,  practitioners,  educators  and  researchers.  Although  it  draws  heavily  from  current 
research — for  example  describing  state-of-the-art  tools,  techniques  and  technologies — it 
does  not  require  a  Ph.D.  to  read,  understand  and  learn  to  act  on  the  material.  Any 
acquisition  manager  with  a  vision,  or  who  does  not  feel  the  current  acquisition  system 
(even  as  reformed)  is  as  efficient  and  effective  as  it  can  be,  should  be  able  to  appreciate 
this  book  and  apply  its  concepts  and  methods  in  the  workplace.  This  is  the  central 
objective  of  the  book. 


M.E.N.  October  1999,  Monterey,  California. 
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Learning  objectives 


The  book  also  addresses  five  learning  objectives.  Through  this  book,  the  reader  should  be  able  to: 

Understand  and  appreciate  the  importance  of  acquisition  as  a  strategic  activity. 

Understand  the  fundamental  differences  between  traditional  and  alpha  contracting,  and  understand 
alpha  contracting’s  strengths  and  limitations. 

Differentiate  radical  process  change  from  incremental  improvement.  Reengineering  techniques  build 
upon  those  of  TQM,  yet  they  differ  in  many  respects. 

Redesign  contracting  processes  for  dramatic  performance  gains.  Methods  and  technologies  discussed 
this  book  are  applied  directly  to  contracting  processes  to  ensure  grounded,  practical  understanding. 

Follow  the  references  to  pursue  deeper  research  and  understanding  in  the  above  topics.  A  rich  set  of 
references  can  guide  the  reader's  exploration  into  the  background,  subtleties  and  complementary 
applications  of  the  lessons  presented  in  this  book. 
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Chapter  1  -  Acquisition  Criticality 


Material  presented  in  this  introductory  chapter  draws  from  an  Acquisition  Review  Quarterly  Special  Issue 
on  Managing  Radical  Change  (Nissen,  Snider  and  Lamm  1998).  Acquisition  represents  a  critical  process  to 
the  Department  of  Defense  (DoD).  In  its  current  usage,  the  term  acquisition  pertains  to  the  strategy, 
planning,  procurement,  contracting,  financing,  program  management  and  logistics  required  to  develop, 
produce  and  support  weapon  systems  and  other  materiel  required  to  accomplish  the  defense  mission.  The 
breadth  of  this  term  indicates  the  acquisition  process  does  not  apply  solely  to  the  DoD;  rather,  most 
enterprises  in  the  public  and  private  sectors  engage  in  acquisition.  One  can  argue  that  the  acquisition 
process  is  critical  for  the  survival  of  commercial  and  defense  enterprises  alike. 

We  say  that  acquisition  represents  a  critical  process  because  it  satisfies  requirements  that  are  essential 
to  survival;  that  is,  without  effective  acquisition,  neither  military,  commercial,  government  nor  any  other 
major  enterprise  can  function  effectively.  Indeed,  in  the  article  above,  Nissen  et  al.  draw  an  analogy  with  the 
human  body,  comparing  acquisition  to  such  vital  bodily  functions  as  eating,  drinking  and  breathing.  Such 
functions  are  clearly  critical  for  survival,  and  every  athlete  understands  effective  food,  drink  and  air 
“acquisition”  is  paramount  for  athletic  performance  (e.g.,  running,  cycling,  strength). 

Despite  this  critical  role,  however,  the  acquisition  process  suffers  from  neglect.  In  the  DoD  as  well  as 
industry,  acquisition  has  long  been  relegated  to  the  ’’end  of  the  line”  with  respect  to  executive  attention, 
funding,  innovation,  training,  career  development  and  other  key  enterprise  attributes.  In  the  DoD  for 
example,  we  have  long  heard  funding  and  prioritization  arguments  based  on  the  "tooth  vs.  tail"  metaphor; 
that  is,  if  an  organization  is  financially  constrained  and  unable  to  procure  sufficient  assets  to  support  all  of 
its  needs  and  desires,  then  priority  should  be  given  to  weapons  and  battle  assets  (i.e.,  the  teeth)  over 
administration,  support  and  even  logistics.  This  appears  to  be  very  rational,  for  it  has  undoubtedly  been  said 
that  one  cannot  fight  wars  with  contract  administrators  and  word  processors. 

Until  recently,  Corporate  America  long  relied  on  this  same  argument.  Although  not  charged  with 
fighting  wars,  few  corporations  would  hesitate  to  shift  discretionary  spending  from  Quality  Assurance  to 
Manufacturing,  from  Customer  Service  to  Marketing,  from  Purchasing  to  Research  and  Development 
(R&D)  and  like  prioritizations.  However,  in  the  Eighties  industry  discovered  that  quality  represents  a 
critical  performance  factor,  that  customers  are  increasingly  demanding  quality  products,  and  even  more 
importantly,  that  emphasizing  quality  could  actually  save  .cost  and  reduce  cycle  time.  This  represents  one  of 
the  key  messages  from  Total  Quality  Management. 

Likewise,  firms  discovered  that  people — both  outside  the  organization  and  within — increasingly 
demand  courteous  and  responsive  customer  service,  and  that  the  most  brilliant  marketing  campaign  in  the 
world  is  ineffective  at  winning-back  a  customer  lost  to  poor  service.  And  whereas  R&D  represents  the 


1 


fundamental  mechanism  for  new  product  and  service  development  for  the  Hierarchy  (cf.  Williamson  1985 
for  comparison  of  markets  and  hierarchies),  the  time  from  basic  research  to  new  product  introduction  can  be 
very  long.  This  limits  a  firm's  agility,  flexibility  and  responsiveness  to  unforeseen  changes  in  the 
environment  and  competitive  arena  (Porter  1985);  so  many  progressive  firms  are  forming  strategic  networks 
with  other  organizations. 

Widespread  supply-chain  integration  Just-in-time  inventory  practices,  virtual  organizations,  mass 
customization  and  other  contemporary  business  approaches  have  required  a  radical  change  in  the 
acquisition  process  of  leading  firms.  For  example,  the  procurement  focus  has  shifted  away  from  arms-length 
transactions  and  more  toward  trust-based  relationships.  Although  price  is  still  vitally  important  (as  always), 
it  is  no  longer  necessarily  more  so  than  capability,  quality,  reliability  and  trustworthiness.  In  many  cases,  the 
relationship  established  with  a  particular  vendor,  customer,  distribution  channel  or  even  a  competitor  makes 
the  difference  between  being  first  to  market  with  an  innovation  and  missing  the  product  cycle  completely — 
perhaps  while  haggling  over  five  percent  of  the  current  transaction's  purchase  price.  In  today’s  era  of 
downsizing,  global  operations  and  exploding  information,  progressive  companies  have  realized  the 
environment  has  shifted  abruptly  and  effected  radical  change  where  appropriate. 

Recently,  we  find  that  acquisition  has  been  achieving  an  increasing  level  of  importance  in  the  DoD  as 
well.  A  new  emphasis  on  commercial  off-the-shelf  (COTS)  equipment  and  software,  for  example,  and  a 
renewed  commercial  emphasis,  higher  simplified  acquisition  threshold  and  preference  for  commercial 
specifications  and  standards  exemplify  this  importance.  The  DoD  acquisition  guidelines  even  establish  as  a 
goal  to  conduct  "business  more  like  business"  (DoD  Instruction  5000  1996).  We  also  note  increasing 
defense  partnerships  with  industry,  less  reliance  on  a  shrinking  defense-unique  industrial  base,  process 
reengineering,  electronic  commerce  and  other  advanced  initiatives  occurring  in  the  DoD,  with  much  the 
same  intensity  that  we  observed  in  industry  a  few  years  ago.  Indeed,  realizing  the  importance  of  acquisition, 
the  former  Secretary  of  Defense  challenged  the  Acquisition  Workforce  to  effect  a  50%  reduction  in  the 
cycle  time  required  to  develop  and  field  major  weapons  systems  (Perry  1994).  This  represents  a  call  for 
radical  change  of  reengineering  proportions. 

In  1997,  the  Secretary  of  Defense  acknowledged  that  the  acquisition  process  limited  battlefield 
information,  mobility  and  speed,  and  he  promulgated  numerous  initiatives  (e.g.,  the  Defense  Reform 
Initiative,  Cohen  1997)  to  improve  acquisition  processes.  Referring  back  to  our  metaphor  from  above,  the 
"tooth  vs.  tail"  argument  no  longer  holds.  Notwithstanding  our  breathtaking  military  performance  in  the 
Gulf  War,  for  example,  armored  units  were  restrained  by  the  logistical  chain.  Our  ability  to  strike  with 
overwhelming  force  required  patience  and  persistence  as  we  amassed  troops,  supplies  and  battlefield  assets 
in  nearby  countries.  Even  our  theater  information  systems  were  critically  dependent  on  relationships  with 
commercial  vendors  for  equipment,  software  and  bandwidth  in  the  region. 

Metaphorically,  regardless  of  the  number  and  size  of  one's  teeth,  you  can  only  run  as  fast  as  your  tail 
can  follow.  And  with  slow,  bureaucratic,  cumbersome,  inflexible  and  unresponsive  procurement  and 
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logistics  processes,  battlefield  speed  is  severely  constrained  after  the  first  few  days  of  intensive  conflict. 
Indeed,  with  the  Defense  Reform  Initiative,  we  fmd  that  the  acquisition  process  is  now  on  verge  of 
becoming  strategic  to  the  military.  Acquisition?  Strategic?  This  represents  a  radical  concept  for  the  DoD.  A 
concept  that  calls  for  concomitant  radical  change. 

In  this  book,  we  address  radical  change  for  the  DoD  through  process  innovation,  with  particular 
emphasis  on  the  contracting  process,  and  examine  in  detail  one  high-leverage  approach  to  innovating  the 
contracting  process:  alpha  contracting.  Specifically,  in  the  following  chapter,  we  discuss  alpha  contracting 
with  direct  comparisons  and  contrasts  to  what  we  call  the  "traditional"  contracting  process.  We  outline  a 
number  of  important  advantages  and  disadvantages  associated  with  alpha  contracting,  and  through  example, 
we  introduce  an  alpha  contracting  decision  model  that  can  be  used  by  contract  managers  to  assess  the 
potential  risks  and  benefits  of  alpha  contracting.  In  the  subsequent  chapter,  we  provide  an  overview  of 
reengineering  and  process  innovation,  making  specific  note  of  similarities  and  differences  between  process 
innovation  and  improvement.  We  then  explain  useful  analytical  frameworks,  tools  and  techniques  employed 
for  process  innovation  and  show,  again  through  examples,  how  such  approaches  can  be  used  to  innovate  the 
contracting  process.  The  final  chapter  integrates  the  preceding  discussion  to  show  how  even  the  alpha 
contracting  process  can  be  further  enhanced  through  process  innovation.  Each  chapter  includes  a  summary 
and  some  questions  and  answers  to  ensure  comprehension  of  key  points.  The  book  concludes  with  a  set  of 
references  to  support  the  reader's  continued  learning  along  these  lines. 


CHAPTER  1  SUMMARY 

In  its  current  usage,  the  term  acquisition  pertains  to  the  strategy,  planning,  procurement,  contracting, 
financing,  program  management  and  logistics  required  to  develop,  produce  and  support  weapon  systems 
and  other  materiel  required  to  accomplish  the  defense  mission.  The  breadth  of  this  term  indicates  the 
acquisition  process  does  not  apply  solely  to  the  DoD.  Rather,  most  enterprises  in  the  public  and  private 
sectors  engage  in  acquisition,  and  one  can  argue  that  the  acquisition  process  is  critical  for  the  survival  of 
commercial  and  defense  enterprises  alike. 

Widespread  supply-chain  integration,  just-in-time  inventory  practices,  virtual  organizations,  mass 
customization  and  other  contemporary  business  approaches  have  required  a  radical  change  in  the 
acquisition  processes  of  leading  firms.  Recently  we  find  that  acquisition  has  been  achieving  an  increasing 
level  of  importance  in  the  DoD  as  well.  Past  and  present  Defense  Secretaries  have  challenged  the 
Acquisition  Workforce  to  effect  a  50%  reduction  in  the  cycle  time  required  to  develop  and  field  major 
weapons  systems  and  acknowledged  that  acquisition  (especially  procurement  and  logistics)  now  limit 
battlefield  information,  mobility  and  speed.  Referring  back  to  our  metaphor  from  above,  the  "tooth  vs.  tail" 
argument  no  longer  holds.  This  book  addresses  radical  change  for  the  DoD  through  process  innovation, 
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with  particular  emphasis  on  the  contracting  process,  and  examines  in  detail  one  high-leverage  approach  to 
innovating  the  contracting  process:  alpha  contracting. 


CHAPTER  1  QUESTIONS 

1 .  What  functional  activities  are  generally  included  under  the  term  acquisition ? 

2.  What  contemporary  business  approaches  have  required  a  radical  change  in  the  acquisition  process  of 
leading  firms? 

3.  What  kinds  of  battlefield  and  fleet  activities  can  be  constrained  by  a  poorly  performing  acquisition 
process? 
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CHAPTER  1  ANSWERS 


1.  Strategy,  planning,  procurement,  contracting,  financing,  program  management  and  logistics. 

2.  Widespread  supply-chain  integration,  just-in-time  inventory  practices,  virtual  organizations,  mass 
customization  and  others. 

3.  Battlefield  information,  mobility  and  speed. 
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Chapter  2  -  Alpha  Contracting 


This  chapter  is  written  to  describe  alpha  contracting  as  an  innovative  acquisition  reform  technique  that  has 
now  been  successfully  employed  for  procurement  of  numerous  products  and  services.  We  first  provide  a 
general  description  of  the  baseline  (i.e.,  "traditional")  contracting  process  that  is  still  practiced  in  many 
acquisitions.  This  is  followed  by  a  high-level  overview  of  the  alpha  contracting  process.  To  support 
comparative  analysis,  we  summarize  alpha  contracting  experience  on  a  pioneering  weapon  system  program: 
the  Joint  Standoff  Weapon  (JSOW)  system.  The  chapter  then  builds  upon  these  process  descriptions  and 
JSOW  experience  to  formulate  a  decision  model  to  be  used  for  assessing  the  likelihood  of  alpha  contracting 
success. 


BASELINE  CONTRACTING  PROCESS 

As  noted  above,  the  baseline  (i.e.,  "traditional”)  contracting  process  is  described  here  to  enhance  both 
comparison  and  contrast  with  alpha  contracting.  This  approach  is  consistent  with  the  specification  of  an  “as 
is”  (i.e.,  baseline)  process  model  in  most  business  process  reengineering  (BPR)  projects  or  other 
engagements  involving  radical  change.  And  as  we  shall  see,  the  transition  to  alpha  contracting  represents  a 
radical  change  indeed.  Alpha  contracting  is  now  broadly  employed  to  procure  both  products  and  services, 
but  its  application  is  focused  primarily  on  relatively  small,  straightforward  acquisitions  (see  Schutter  1998). 
However,  the  techniques  are  in  no  way  limited  to  such  acquisitions,  as  the  JSOW  example  (an  ACAT  ID 
program)  shows. 

Further,  the  focus  of  this  section  is  initially  on  contracting  by  negotiation  (e.g.,  as  described  in 
FAR  Part  15),  as  applicable  to  procurement  of  most  major  systems.  The  scale,  scope  and  complexity  of 
such  major  system  acquisitions  present  a  number  of  challenges  in  terms  of  management  and  integration  that 
can  leverage  the  payoff  from  effective  alpha  contracting  on  ACAT  I  programs.  Thus,  their  examination 
reveals  many  insights  into  alpha  contracting  strengths  and  limitations  that  do  not  manifest  themselves 
through  smaller,  simpler  procurements. 

The  principal  elements  comprising  the  baseline  contracting  process  flow1  are  delineated  in  Figure 
1.  The  activities  performed  by  the  buyer  (e.g.,  Government  Program  Office)  are  listed  as  linked  activities 
under  the  “Government”  column  heading  and  those  performed  by  the  seller  (e.g.,  commercial  contractor) 
are  listed  in  like  fashion  under  the  “Contractor”  heading.  Those  activities  performed  jointly  are  listed  in  the 
center  column  to  indicate  their  cooperative/collaborative  nature.  This  process  notation  combines  aspects  of 
the  DoD  standard  Integrated  Definition  (IDEF)  with  the  “swimlanes”  (marked  by  dotted  vertical  lines)  that 
have  emerged  as  a  common  modeling  practice  in  process  redesign2.  Our  general  process  baseline  represents 
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a  composite  view  synthesized  from  several  sources3  and  years  of  experience. 


Government  Joint  Contractor 


Because  this  baseline  contracting  process  is  very  common,  we  outline  its  key  steps  only  briefly 
here.  For  purpose  of  comparison  and  contrast  between  this  baseline  process  and  its  alpha  counterpart,  we 
choose  to  begin  the  process  description  with  the  preparation  of  a  statement  of  work  (SOW)  for  prospective 
solicitation  and  contract  (labeled  “Prep  SOW”  in  the  figure).  Clearly,  many  important  activities  take  place 
prior  to  SOW  development  (e.g.,  the  Government  often  solicits  industry  input  through  its  request-for- 
information  (RFI)  instrument).  But  most  of  such  activities  do  not  accentuate  differences  between  traditional 
and  alpha  contracting,  so  we  omit  them  from  the  diagram4.  In  the  next  step  (labeled  “Draft  RFP”  in  the 
figure),  the  other  major  RFP  sections  are  composed,  generally  by  the  technical  team  and  one  or  more 
contract  specialists.  With  an  approved  RFP,  a  synopsis  is  followed  by  a  series  of  iterative  steps  leading  to 
proposal  submittal,  fact-finding  and  eventually  contract  negotiation. 

Notice  the  multiple  feedback  loops  depicted  at  various  points  along  the  process  flow.  Experience 
indicates  that  few  SOWs,  RFPs,  proposals  or  contracts  are  successfully  developed  without  undergoing 
several  iterations  and  revisions.  This  is  particularly  true  for  major  weapon  systems  in  today's  dynamic  and 
uncertain  budgetary  environment.  Clearly  each  "trip”  back  through  such  a  feedback  loop  consumes  precious 
acquisition  time  and  money.  Notice  also — in  the  baseline  process  flow — that  the  fact-finding  step  represents 
the  first  activity  in  which  the  Government  and  contractor  personnel  work  jointly  toward  the  end  product:  a 
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definitized  contract  for  award.  Although  many  contracting  activities  continue  well  beyond  this  point,  for  our 
purpose  of  comparison  and  contrast  with  the  alpha  contracting  process,  this  process  model  and  description 
provide  the  necessary  grist  for  understanding  and  communicating  the  key  process  activities  and  sequencing. 


ALPHA  CONTRACTING  PROCESS 

Using  the  same  process  notation,  the  principal  alpha  contracting  process  elements  are  delineated  in  Figure 
2.  Notice,  at  first  glance,  how  the  overall  pattern  of  the  process  flow  differs  considerably  from  that 
pertaining  to  the  baseline  contracting  process  presented  above  (esp.  in  terms  of  process  length,  simplicity 
and  collaboration).  Also  take  note  that  this  latter,  alpha  version  of  the  process  accomplishes  all  of  the  same 
results  required  by  its  baseline  counterpart  above.  Like  the  baseline,  this  general  alpha  process  model 
represents  a  composite  view  synthesized  from  several  sources5  and  experience. 


Government  Joint  Contractor 


Briefly,  as  with  the  baseline  contracting  process,  we  choose  to  also  begin  the  alpha  contracting 
process  with  SOW  preparation,  which  precedes  the  composition  of  a  draft  RFP.  In  many  instances  of  alpha 
contracting,  the  SOW  step  is  replaced  by  a  statement  of  objectives  (SOO),  which  prescribes  only  high-level 
goals  for  a  system,  as  opposed  to  the  work  to  be  done.  However,  a  SOW  must  still  be  developed  by 
someone  (e.g.,  either  the  Government  or  contractor).  And  the  underlying  steps  are  essentially  the  same 


regardless  of  whether  performed  by  the  buyer  or  seller.  Hence  this  SOO  approach  effectively  transfers  the 
SOW-development  task  from  the  Government  to  the  contractor  or  defers  its  creation  until  some  point  after 
contract  award. 

The  alpha  contracting  process  delineated  in  Figure  2  strikes  a  balance  between  Government-only 
and  contractor-only  SOW  development.  Notice  the  placement  of  these  activities  in  the  center  column  of 
Figure  2  to  indicate  the  activities  are  performed  jointly  by  the  government  and  contractor  teams.  Once  an 
acquisition  strategy  and  plan  (often  including  a  preliminary  RFP)  have  been  developed  by  the  Government6, 
technical  personnel  from  both  the  government  PMO  and  contractor  organization  work  together  to  develop 
the  draft  SOW,  as  do  contracts  and  pricing/estimating  personnel  to  develop  the  draft  RFP.  Instead  of 
iteratively  trying  to  accomplish  these  tasks  "at  arms  length" — and  mailing  formal  documents  back  and 
forth — as  above  in  the  process  baseline,  the  integrated  product  team  (IPT)  approach  is  employed  to  jointly 
develop  these  key  documents. 

This  approach  can  be  described  in  terms  of  an  investment.  Both  teams  invest  the  time  and  attention 
of  key  personnel  up-front  to  jointly  develop  these  contracting  documents.  The  investment  has  objectives 
that  include:  1)  improving  communications;  2)  decreasing  the  number  of formal  RFP  iterations,  revisions 
and  rework  required  to  correct  misunderstandings,  errors  and  mistakes;  3)  reducing  the  cycle  time 
(procurement  administrative  lead  time  or  PALT)  required  for  contracting;  4)  increasing  the  level  of  trust, 
openness  and  mutual  respect  between  the  government  and  contractor  teams;  and  5)  decreasing  the  overall 
cost — both  for  the  Government  and  contractor — associated  with  the  procurement. 

Continuing  the  IPT  theme,  notice  that  the  “develop  proposal(s)”  activity  is  also  accomplished 
jointly;  that  is,  the  same  people — both  government  and  contractor — who  collaborate  to  develop  the  SOW 
and  RFP  together  will  continue  their  collaboration  to  transform  this  SOW/RFP  document — through  a 
contractor  proposal — and  make  it  the  contract.  Feedback  to  both  the  government  and  contractor  activities 
accompanies  this  key  process  step.  As  above,  the  process  proceeds  through  the  business 
clearance/negotiation  targets  steps,  but  notice  the  separate  fact-finding  activity  is  absent  from  the  alpha 
contracting  process  model.  The  point  is,  the  collaborative  nature  of  the  preceding  process  activities  (esp. 
SOW/RFP  preparation  and  proposal  development)  obviates  the  need  to  conduct  formal  fact-finding  as  a 
separate,  sequential  activity.  In  the  alpha  contracting  process,  this  “step”  takes  place  concurrently  with  the 
development  of  the  RFP  and  proposal.  This  concurrency  contributes  considerably  to  the  shorter  process 
length  that  is  observable  by  comparing  the  two  figures. 

After  the  negotiation  clearances  are  obtained,  the  formal  negotiation  would  proceed  as  before — in 
theory — with  the  two  sides  achieving  a  meeting  of  the  minds  on  the  contractual  scope,  price  and  language 
for  the  acquisition.  The  key  difference  is  that,  at  some  point,  the  “collaborative”  nature  of  the  activities 
represented  above  has  the  potential  to  breakdown.  Negotiation  represents  a  stressful  activity  that  often 
reduces  to  a  zero-sum  game.  Hence  collaboration  may  give  way  to  confrontation,  even  before  the  formal 
negotiation  step  has  been  reached.  We  will  return  to  this  point.  But  we  note  here  that  such  confrontation  has 
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the  potential  to  negate  many  of  the  key,  trust-based  advantages  of  the  alpha  contracting  process,  particularly 
as  the  same  individuals  are  expected  to  jointly  collaborate  again  on  the  next  fiscal  year’s  procurement. 


ALPHA  CONTRACTING  ADVANTAGES  AND  DISADVANTAGES 

Nearly  any  process  change  is  expected  to  offer  both  advantages  and  disadvantages.  A  common  saying  in  the 
software  domain,  for  example,  is  that  there  is  no  "silver  bullet"  (e.g.,  see  Brooks  1987).  This  means  that  no 
single  change  or  innovation  is  sufficient  to  remove  all  problems  from  a  process.  It  implies  that  every  such 
change  or  innovation  also  introduces  its  own  share  of  new  problems.  The  innovation  of  alpha  contracting 
into  the  acquisition  domain  is  no  different.  The  key  is  to  understand  the  relative  advantages  and 
disadvantages  associated  with  a  new  change  or  innovation  and  appreciate  the  circumstances  in  which  it  is 
most  likely  to  be  successful  and  effective.  In  this  section,  we  explore  the  relative  advantages  and 
disadvantages  of  alpha  contracting. 


Relative  Advantages  of  Alpha  Contracting 

Alpha  contracting  provides  a  number  of  advantages.  Summarizing  from  our  discussion  above,  the  alpha 
process  can  be  described  in  terms  of  an  investment.  Both  teams  invest  the  time  and  attention  of  key 
personnel  up-front  to  jointly  develop  contracting  documents,  with  the  objectives  of:  1)  improving 
communications;  2)  decreasing  the  number  of formal  RFP  iterations,  revisions  and  rework  required  to 
correct  misunderstandings,  errors  and  mistakes;  3)  reducing  the  cycle  time  (procurement  administrative  lead 
time  or  PALT)  required  for  contracting;  4)  increasing  the  level  of  trust,  openness  and  mutual  respect 
between  the  government  and  contractor  teams;  and  5)  decreasing  the  overall  cost — both  for  the  Government 
and  contractor — associated  with  the  procurement.  We  briefly  expand  on  each  advantage  in  turn. 

Improved  communications.  Alpha  contracting  involves  a  considerable  number  of  joint  activities 
performed  by  the  buyer  and  seller,  or  Government  and  contractor  in  the  typical  federal  acquisition.  By 
performing  procurement  activities  jointly,  team  members  from  both  sides  have  frequent  opportunities  to 
communicate  regarding  a  particular  acquisition.  This  helps  rectify  misunderstandings,  on  both  sides  of  the 
contract,  and  augments  agreement  and  commonality  of  understanding  between  buyers  and  sellers.  Further, 
alpha  contracting  generally  decomposes  large  teams  (e.g.,  representing  the  buyer  and  seller)  into  small  ones 
(e.g.,  representing  Engineering,  Manufacturing,  Materiel,  Logistics,  Pricing,  Contracts),  so  that  engineers 
can  work  directly  with  engineers,  manufacturing  people  can  work  directly  with  manufacturing  people,  and 
so  forth.  This  affords  people,  from  opposite  sides  of  the  contract,  to  communicate  directly  and  informally 
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with  their  peers  and  counterparts. 


Decreased  iterations.  Improved  communications  promote  common  understanding  between  parties  on 
opposite  sides  of  the  contract.  A  common  understanding  reduces  the  chances  of  misunderstandings,  errors 
and  mistakes  propagating  themselves  into  formal  documents.  Rather,  where  opportunities  for  such 
misunderstandings,  errors  and  mistakes  occur,  members  of  alpha  contracting  teams  can  work  together — 
directly  and  informally — to  ask  questions,  challenge  assumptions  and  test  beliefs  to  ensure  a  common  basis 
for  proposing  and  contracting.  If  no  misunderstandings,  errors  and  mistakes  are  allowed  to  propagate  into 
formal  contractual  documents,  conceivably  only  one  RFP  and  proposal  are  required  to  definitize  a  contract. 

Reduced  Procurement  Administrative  Lead  Time.  Each  formal  iteration  of  contractual  documentation 
consumes  time  and  resources.  For  instance,  each  time  a  RFP,  proposal  or  other  contractual  document  is 
revised,  time  and  resources  are  required  to  change  the  document  (e.g.,  through  amendment,  revision),  gain 
internal  approval  (e.g.,  management  review,  legal  review)  and  physically  deliver  the  revised  documents 
(e.g.,  mail,  express  delivery).  Once  received  by  the  other  party  (e.g.,  the  seller),  additional  time  is  required 
to  understand  the  changes,  make  distribution  through  the  contractor’s  organization  and  respond  to  the 
changes  (e.g.,  through  a  revised  proposal).  Each  such  iteration  consumes  time  and  adds  to  PALT.  It  follows 
that  PALT  can  be  reduced  by  decreasing  the  number  of  iterations. 

Increased  trust.  Increasing  the  level  of  trust,  openness  and  mutual  respect  between  the  government  and 
contractor  teams  stems  from  professionals  working  together  in  peer  teams  toward  a  common  goal.  Through 
such  direct  interaction,  parties  on  both  sides  of  the  contract  soon  learn  that  deception  is  counterproductive, 
and  by  cooperating  on  various  elements  and  phases  of  an  acquisition,  people  on  such  peer  teams  learn  to 
appreciate  both  the  areas  of  agreement  and  disagreement  between  themselves  and  their  counterparts. 
Understanding  such  areas  up-front  helps  people  on  opposite  sides  of  the  contract  focus  on  issues  instead  of 
personalities.  It  is  much  easier  to  work  with  someone  who  "disagrees"  than  one  who  "is  trying  to  cheat,"  for 
example. 

Decreased  cost.  Decreasing  the  overall  cost — both  for  the  Government  and  contractor— associated  with  a 
procurement  is  largely  a  function  of  reduced  PALT  above.  But  decreased  cost  also  derives  from  the  other 
factors  above.  For  instance,  improved  communications  reduce  the  cost  associated  with  repeating,  clarifying 
and  justifying  contractual  documents.  The  preparation  cost  associated  with  multiple  iterations  of  contractual 
documents  can  be  reduced  as  each  iteration  is  eliminated.  And  through  increased  trust,  parties  on  both  sides 
can  reduce  the  amount  of  managerial  oversight  and  review  associated  with  a  procurement.  Notice  that 
reduced  oversight  and  review  does  not  imply  no  oversight  and  review.  Cost  savings  derive  from  the 
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reduction  facilitated  through  increased  trust. 


Relative  Disadvantages  of  Alpha  Contracting 

Alpha  contracting  provides  a  number  of  disadvantages  as  well.  Principal  among  them  are:  1)  increased  up¬ 
front  resources;  2)  negotiation  difficulties;  and  3)  competitive  sourcing  complexities.  As  above,  we  briefly 
expand  on  each  disadvantage  in  turn. 

Increased  up-front  resources.  We  noted  above  the  considerable  number  of  joint  procurement  activities 
performed  by  buyer  and  seller.  Joint  work  between  buyer  and  seller  can  consume  considerable  time.  For 
instance,  the  improved  communications  from  above  do  not  come  without  people  on  both  sides  of  the 
contract  investing  the  time  to  understand  one  another.  And  trust  between  people — particularly  former 
contractual  adversaries — requires  time  and  positive  reinforcement  to  develop.  Moreover,  the  time  required 
for  alpha  contracting  occurs  at  the  beginning  of  a  procurement  cycle  (e.g.,  beginning  with  SOW/SOO 
development)  and  requires  additional  time  and  resources  to  plan  and  coordinate  joint,  alpha  contracting 
sessions.  It  is  not  uncommon  for  major  programs  to  send  a  dozen  or  more  key  people  from  a  program  office 
(e.g.,  the  Program  Manager,  Contracting  Officer,  Chief  Engineer)  to  spend  weeks  with  their  counterparts  at 
a  contractor’s  facility  for  alpha  contracting  meetings.  Such  key  people  tend  to  be  very  busy  and  overworked 
as  it  is.  The  additional  demands  of  alpha  contracting,  over  an  extended  period  of  time,  represent  a  distinct 
disadvantage  of  this  technique.  Notwithstanding  the  opportunity  for  decreased  PALT  and  reduced  overall 
cost,  the  increased  up-front  resources  required  for  effective  alpha  contracting  can  be  prohibitive  in  the 
contracting  office  without  foresight  or  some  flexibility  in  scheduling  resources. 


Negotiation  difficulties.  Negotiation  is  often  an  adversarial  activity,  and  the  traditional,  position-based 
negotiation  rarely  engenders  trust  and  mutual  respect  between  parties.  Yet  there  are  times  during  the 
contracting  cycle — whether  through  traditional  or  alpha  contracting — when  disagreements  and  disputes 
cannot  be  resolved  through  cooperative  discussion.  When  alpha  contracting  "teammates”  attempt  to  settle 
such  disagreements  and  disputes,  the  level  of  trust  can  be  diminished  and  affect  the  ability  of  the  associated 
individuals  to  continue  working  cooperatively.  This  is  particularly  the  case  when  one  party  or  the  other  feels 
disadvantaged  through  the  result.  Thus,  alpha  contracting  appears  to  have  a  good  place  so  long  as  the 
intensity  of  disagreements  and  disputes  remains  within  a  level  that  can  be  resolved  cooperatively.  Beyond 
this  level,  the  alpha  contracting  process  can  breakdown.  One  strategy  is  to  have  as  many  issues  resolved 
through  alpha  contracting  as  possible,  and  then  shunt  the  remaining  unresolved  issues  to  formal  negotiation 
at  the  bargaining  table.  A  second  strategy  is  management  intervention  in  issues  that  cannot  be  resolved  by 
the  alpha  contracting  teams  through  cooperative  discussion. 
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Competitive  sourcing  complexities.  Alpha  contracting  is  used  almost  exclusively  for  sole-source 
procurements.  The  demands  of  teaming  noted  above — particularly  the  up-front  time  and  resource 
requirements — are  challenging  enough  for  the  buyer  to  work  cooperatively  with  a  single  contractor.  In  a 
competitive  sourcing  scenario,  in  which  multiple  competing  contractors  are  involved,  these  challenges  are 
exacerbated.  Many  program  offices  would  simply  fmd  the  up-front  requirements  prohibitively  expensive 
and  time-consuming  to  pursue  alpha  contracting  with  multiple  vendors.  Additionally,  the  same  kinds  and 
levels  of  trust  developed  between  buyer  and  seller  are  unlikely  to  materialize  between  competing  vendors. 
For  instance,  it  would  be  unrealistic  to  expect  even  two  firms,  say  which  are  competing  for  a  single  contract 
award,  to  share  details  associated  with  their  product  designs,  technical  approaches  and  costs.  If  a  program 
office  pursues  alpha  contracting  with  multiple  vendors,  it  will  probably  have  to  establish  separate 
government-contractor  teams  with  each  vendor.  And  the  Government  has  duties  not  to  share  contractors’ 
proprietary  proposal  information  with  their  competitors,  so  each  government  team  may  need  to  involve 
different  people  from  the  program  office.  For  instance,  the  engineer,  cost/price  analyst  and  contract 
specialist  assigned  to  participate  in  an  alpha  contracting  team  for  Vendor  A  may  need  to  be  different  people 
than  the  ones  assigned  to  participate  in  an  alpha  contracting  team  for  Vendor  B.  This  further  exacerbates  the 
resource  constraints  imposed  by  alpha  contracting  and  complicates  source  evaluation  and  selection. 


JSOW  EXPERIENCE 

As  noted  above,  examination  of  alpha  contracting  as  practiced  on  the  JSOW  program  elucidates  a  number 
of  strengths  and  weaknesses  of  this  approach  to  acquisition  reform.  It  is  important  to  stress  that  although  a 
number  of  factors  make  the  JSOW  program  and  alpha  contracting  process  unique,  none  of  the  principles, 
tools  or  techniques  described  in  this  section  is  restricted  to  just  the  JSOW  program.  In  other  words,  the 
JSOW  experience  is  broadly  applicable  to  a  wide  variety  of  different  programs,  systems  and  contracting 
situations.  Here,  we  draw  fromNissen  (1998a)  to  outline  some  of  the  key  contextual  factors  associated  with 
the  JSOW  program  and  then  summarize  the  key  benefits  realized  by  JSOW  through  alpha  contracting. 


JSOW  Contextual  Factors 

At  the  time  of  our  original  field  research  (1998),  the  program  had  progressed  very  successfully  through  the 
Engineering  and  Manufacturing  Development  (EMD)  contract  for  development  of  the  Baseline  (BLU-97) 
vehicle.  And  it  was  executing  a  Low  Rate  Initial  Production  (LRIP)  Lot  1  contract  for  BLU-97  while  in  the 
midst  of  contracting  for  its  second  LRIP  lot.  Interestingly,  JSOW  contracting  has  not  involved  competitive 
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procurement  since  the  EMD  award.  This  is  the  primary  reason  for  our  emphasis  on  the  sole-source 
contracting  process.  Further,  the  program  elected  to  make  a  change  in  contract  type  for  the  current 
contracting  cycle.  Whereas  the  EMD  and  LRIP  Lot  1  contracts  were  and  are  executed  on  a  cost- 
reimbursement  type  contract  (LRIP  Lot  1  was  originally  priced  as  an  EMD  contract  option),  a  fixed-price 
incentive  (FPI)  contract  is  contemplated  for  LRIP  Lot  2.  This  change  in  contract  type  effects  a  substantial 
transfer  of  risk  from  the  Government  to  the  contractor  and  can  produce  a  shift  in  the  relative  degree  of 
cooperation  versus  confrontation  experienced  in  alpha  contracting.  Also,  the  JSOW  is  categorized  as  an 
ACAT  ID  (i.e.,  major)  DoD  program  and  represents  a  complex,  software-intensive  weapon  system  that  has 
not  yet  completed  its  operational  flight  test  activities  for  all  weapon  system  variants  (i.e.,  BLU-108  and 
Unitary).  These  contextual  factors  can  play  an  important  role  in  decision  making  about  alpha  contracting. 

The  geographical  separation  between  government  project  offices  (Navy  (USN)  in  California  and 
Air  Force  (USAF)  in  Florida)  and  the  contractor  (Raytheon  TI  Systems  (RTIS)  in  Texas)  serve  to 
exacerbate  the  up-front  time  and  personnel  commitments  required  for  alpha  contracting.  Not  only  must  a 
number  of  key  personnel  from  the  government  PMOs  and  contractor  team  invest  a  substantial  amount  of 
time  conducting  the  many,  often-lengthy  joint  activities  required  to  develop  the  technical,  cost  and 
contractual  details  associated  with  a  solicitation,  but  the  government  teams  are  required  to  travel  to  the 
contractor  plant  location  for  the  equivalent  of  several  weeks,  year  after  year.  Thus,  noting  the  alpha 
contracting  process  in  general  is  expensive  and  time  consuming,  we  find  the  geographic  separation  between 
the  contractor  and  government  PMOs  compounds  the  costs  and  difficulties  associated  with  joint 
proposal/contract  development7.  Although  both  the  Government  and  contractor  teams  appear  to  be  learning 
and  improving  the  process  from  year  to  year,  the  current  process  continues  to  place  heavy  demands  on  the 
resources  of  both  teams. 


JSOW  Alpha  Contracting  Benefits 

The  JSOW  benefits  derived  from  alpha  contracting  are  difficult  to  quantify  but  very  real.  Although  the  cycle 
time  for  the  contracting  process  is  shorter  through  alpha  contracting  than  through  the  baseline  contracting 
process  that  came  before,  the  program  is  also  in  a  more  mature  stage  of  development  (i.e.,  LRIP  vs.  EMD). 
Accordingly,  the  government  and  contractor  team  members  now  spend  less  time  performing  the  alpha 
contracting  process  than  its  baseline  counterpart.  This  allows  key  PMO  and  contractor  personnel  to 
concentrate  their  limited  time  and  energy  on  the  critical  technical  and  programmatic  aspects  of  weapon 
system  acquisition,  as  opposed  to  a  lengthy  contracting  cycle  fraught  with  arms-length  document  exchange 
and  rework.  In  today's  environment  of  fiscal  restraint  and  defense  downsizing,  the  time  and  energy  of  key 
acquisition  personnel  represent  severely  constrained  resources.  Enabling  these  officers,  executives, 
managers  and  engineers  to  concentrate  on  weapon  system  development ,  as  opposed  to  administration,  may 
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come  to  represent  one  of  the  most  critical  success  factors  identified  to  date.  However,  it  is  difficult  to 
measure  the  quantifiable  benefits  stemming  from  such  concentration  of  time  and  energy. 

Further  measurement  difficulties  arise  from  other  benefits  that  include:  improved  quality  of  the 
contract  documentation  (which  benefits  contract  administrators  and  program  managers  downstream  after 
contract  award);  increased  understanding  by  team  members  of  key  programmatic,  technical  and  contractual 
issues  that  are  surfaced  and  addressed  early  in  the  contracting  cycle  as  opposed  to  late  in  the  execution 
phase;  and,  the  professional,  trust-based  relationships  that  are  developed  in  the  alpha  contracting  process 
and  carry  over  to  improve  the  character  of  work  and  atmosphere  of  cooperation  that  follows  from 
contracting  into  program  execution.  These  latter  benefits  represent  important  elements  of  the  IPT  process 
that  are  sought  in  modem  government-contractor  partnerships.  The  alpha  contracting  process  appears  to 
help  foster  such  partnership  before  the  execution  phase  of  a  program  begins.  This  benefit  can  effectively 
help  to  move  the  government-contractor  team  along  the  IPT  learning  curve  through  joint  participation, 
coordination  and  work  in  the  contracting  phase.  Although  this  benefit  too  is  difficult  to  quantify,  such 
difficulty  neither  negates  nor  in  any  way  diminishes  its  importance.  As  a  closing  note  for  this  section,  one 
(anonymous)  long-term  JSOW  program  participant  summarizes  the  alpha  contracting  benefits  as  follows:  “I 
believe  the  biggest  benefit  of  IPTs,  which  allow  for  alpha  contracting,  is  pride  of  ownership.  All  of  the  team 
members,  government  and  contractor  alike,  hold  the  success  of  JSOW  as  a  wondrous  accomplishment  of 
which  they  are  all  an  important  part” 


ALPHA  CONTRACTING  DECISION  MODEL 

In  this  section,  we  use  the  preceding  JSOW  discussion  as  a  point  of  departure  for  developing  an  alpha 
contracting  model  that  can  be  used  by  PMs  and  KOs  for  process  design  and  decision  making.  Drawing  from 
Nissen  (1998a),  we  reproduce  a  rough  formalization  of  the  Alpha  Contracting  Decision  Model  through  the 
four  quadrants  and  variables  depicted  in  Table  1.  It  includes  two  dimensions:  1)  locus  of  control  (internal  to 
the  PMO  or  external),  and  2)  stability  (fixed  or  variable  across  program  phases). 


Table  1  Alpha  Contracting  Decision  Model 


Locus  of  Control 

Variable 

Fixed 

Internal: 

(Quadrant  I) 

(Quadrant  II) 

Contract  type 

Alpha  experience 

Competition 

PMO  commitment 

Technical  IPTs 

External: 

(Quadrant  IV) 

(Quadrant  III) 

Program  phase 

ACAT 

Budget/schedule  pressure 

System 

Contractor  openness 

Complexity 

Geography 
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Each  of  the  four  quadrants  may  be  interpreted  roughly  as  follows:  1)  Quadrant  I  -  recurring  PMO 
decision  variables  (i.e.,  same  variables  may  be  revisited  on  each  contracting  cycle);  2)  Quadrant  II  -  fixed 
PMO  decision  variables  (i.e.,  once  decisions  are  made,  these  factors  tend  to  remain  fixed);  3)  Quadrant  III  - 
fixed  externally-imposed  contextual  factors  (i.e.,  important,  but  outside  PM  direct  control);  and  4)  Quadrant 
IV  -  externally-determined  variables  (i.e.,  variable,  but  not  directly  within  PM  direct  control).  PMO  model 
use  can  be  prescribed  concisely:  design  and  focus  decision  making  on  factors  in  quadrants  I  and  II; 
understand,  anticipate  and  react  to  factors  in  quadrants  III  and  IV.  Of  course,  the  critical  decisions  are 
whether  and  when  to  employ  alpha  contracting. 


Table  2  JSOW  Alpha  Contracting  Process  Scoring 


Quadrant 

Factor 

Operationalization 

LRIP  Loti  LRIP  Lot  2 

QI: 

Contract  type 

Cost  vs.  fixed  price 

+  1 

-i 

Competition* 

Sole-source  vs.  competitive 

+1 

+i 

PMO  commitment* 

PM  committed  vs.  ambivalent 

+1 

+i 

Q2: 

Alpha  experience 

Previous  experience  (yes  vs.  no) 

-1 

+1 

Technical  IPTs 

Currently  employed  (yes  vs.  no) 

+  1 

+1 

QIII: 

ACAT 

ACAT  Will  vs.  ACAT  I 

0 

0 

System 

Missile  vs.  other  class 

0 

0 

Complexity 

Simple  vs.  complex  program 

+1 

+1 

Geography 

Collocated  vs.  dispersed 

-1 

-1 

QIV: 

Program  phase 

Production  vs.  EMD 

0 

0 

Budget/Schedule  pressure 

Low  vs.  high 

+1 

-1 

Contractor  openness* 

Open  vs.  closed 

+1 

+1 

Total  Score: 

+5 

+3 

Returning  to  our  JSOW  example  for  exposition,  we  summarize  the  simple  scheme  for  scoring  the 
likelihood  of  alpha  contracting  success  on  a  particular  program.  Although  this  represents  a  preliminary 
scheme,  which  needs  to  be  revisited  and  refined  through  additional  research  to  address  a  number  of  other 
programs,  it  nonetheless  provides  useful  information  regarding  the  potential  likelihood  of  alpha  contracting 
success.  To  calibrate  this  model,  we  have  rated  the  JSOW  experience  with  alpha  contracting  using  a  simple 
ternary  scale:  a)  score  +1  if  a  factor  contributes  to  alpha  contracting  success;  b)  score  -1  if  a  factor  inhibits 
success;  and  c)  score  0  for  factors  neutral  to  alpha  contracting  success.  The  operationalization  and  scoring 
for  JSOW  alpha  contracting  (LRIP  Lot  1  and  2)  experience  is  summarized  for  factors  in  each  quadrant 
through  Table  2. 

To  illustrate  from  Quadrant  I,  the  first  factor  listed  in  the  table — contract  type — is  operationalized 
in  terms  of  cost  vs.  fixed  price.  The  score  (+1)  for  LRIP  Lot  1  is  positive,  because  a  cost-reimbursement 
contractual  environment  can  ease  contractor  tension  about  cost  risk.  Although  this  simply  shifts  cost  risk  to 
the  Government,  absent  a  profit  motive,  the  net  effect  can  often  improve  the  chances  of  successful  alpha 
contracting  through  facilitated  trust  and  cooperation.  Conversely,  the  negative  score  (-1)  for  LRIP  Lot  2 
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reflects  the  shift  to  a  fixed-price  contractual  environment,  which  can  impede  alpha  contracting  efficacy.  The 
assignment  of  scores  to  the  other  factors  is  relatively  straightforward  and  follows  similar  reasoning  and 
analysis.  Briefly  addressing  the  other  factors  listed  under  Quadrant  I,  we  noted  above  several  reasons  why  a 
sole-source  environment  is  more  conducive  to  alpha  contracting  than  a  competitive  procurement,  hence  the 
positive  score  (+1)  for  JSOW.  Next,  the  JSOW  program  office  is  committed  to  alpha  contracting  success 
and  is  willing  to  intervene  to  assure  effectiveness.  Such  management  support  is  important  for  effective  joint 
work  at  lower  organizational  levels,  and  it  enhances  chances  for  alpha  contracting  success. 

From  Quadrant  II  of  the  table,  we  note  alpha  contracting  represents  a  deviation  from  the  traditional 
process,  one  that  can  benefit  from  practice  and  experience.  For  the  JSOW  program,  the  members  had  no 
such  experience  prior  to  LRIP  Lot  1.  This  is  the  reason  for  the  negative  score  (-1)  for  LRIP  Lot  1.  When 
Lot  2  began,  the  team  then  had  the  benefit  of  Lot  1  alpha  contracting  experience,  hence  the  positive  score 
(+1).  Concurrent  use  of  technical  IPTs  is  also  very  beneficial  to  alpha  contracting,  because  it  affords  an 
opportunity  to  integrate  joint  technical  work  (e.g.,  system  engineering)  with  joint  contracting  work  (e.g., 
SOW  development),  without  having  to  change  personnel  or  disrupt  trust-based  relationships.  From  the 
positive  scores  (+1),  it  is  apparent  the  JSOW  program  benefited  from  such  concurrent  technical  IPTs  during 
both  Lots  1  and  2. 

Looking  at  the  Quadrant  III  factors,  we  note  no  particular  benefit  or  limitation  of  using  alpha 
contracting  that  depends  on  a  program's  size  and  importance  (e.g.,  ACAT  designation)  or  the  type  of  system 
being  procured  (e.g.,  missile,  ship,  tank,  truck).  Thus,  these  factors  are  scored  neutrally  (0)  for  JSOW. 
Alternatively,  system  complexity  has  a  strong  influence  over  alpha  contracting  success,  for  the  alpha 
approach  offers  the  greatest  advantages  over  traditional  contracting  when  applied  to  complex  systems.  This 
is  the  reason  for  the  positive  (+1)  score  for  LRIP  Lots  1  and  2.  We  noted  above  the  problem  with  the  large 
amount  of  up-front  time  required  for  alpha  contracting.  Geographically  dispersed  PMOs  and  contractor  sites 
exacerbate  this  problem,  so  this  factor  is  scored  negatively  (-1)  for  both  JSOW  lots.  As  a  note,  with  foreign 
procurement,  this  negative  score  may  need  to  be  increased  even  further  (e.g.,  to  -2). 

Moving  to  the  Quadrant  IV  factors,  as  with  system  complexity,  program  complexity  also  drives 
alpha  contracting  success.  EMD  is  notably  more  complex  than  production  and  follow-on  phases,  so  we 
assign  a  neutral  (0)  score  for  LRIP  Lots  1  and  2  (e.g.,  we  would  have  scored  higher  (+1)  in  the  EMD 
phase).  Budget  and  schedule  pressure  also  impact  alpha  contracting  success.  When  such  pressures  are  low, 
for  example  as  in  LRIP  Lot  1,  joint  teams  enjoy  many  degrees  of  freedom  in  designing  a  mutually- 
beneficial  business  deal  and  can  often  develop  acceptable  approaches  and  solutions  without  having  to  make 
difficult  choices.  When  such  pressures  mount,  however,  affordable  and  effective  programs  often  require 
higher-risk  agreements,  which  are  notably  more  difficult  to  reach  through  trust  and  consensus.  Thus,  we 
assign  a  negative  score  (-1)  for  this  factor  in  LRIP  Lot  2.  Finally,  contractor  openness  has  an  effect  similar 
in  size  and  direction  to  that  of  PMO  commitment  discussed  above.  Because  the  RTIS  management  was 
similarly  committed  to  alpha  contracting,  we  also  score  this  factor  positively  (+1)  for  the  JSOW  program. 
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Notice  from  the  table  entries  that  the  LRIP  Lot  1  score  of  five  exceeds  the  LRIP  Lot  2  value  by 
two  points  and  is  positive.  We  may  propose  a  rough  interpretation  of  this  scoring  scheme  as  follows:  the 
higher  the  score,  the  greater  the  likelihood  of  alpha  contracting  success,  and  negative  scores  (i.e.,  below 
zero)  may  signal  potential  problems  with  the  alpha  approach.  With  this,  the  likelihood  of  success  for  LRIP 
Lot  2  could  be  interpreted  as  somewhat  diminished  with  respect  to  that  of  LRIP  Lot  1,  yet  still  non-negative 
in  value  and  relatively  close  (e.g.,  2  points  apart).  Thus,  relative  caution  may  be  required  when  employing 
the  alpha  approach  on  LRIP  Lot  2.  Further,  the  three  variable  factors  from  the  table  marked  with  asterisks — 
competition,  PMO  commitment,  contractor  openness — could  shift  to  tilt  the  balance  away  from  likely  alpha 
contracting  success  in  subsequent  production  lots. 


CHAPTER  2  SUMMARY 

The  baseline  or  "traditional"  contracting  process  is  very  prevalent  within  the  DoD.  For  our  purposes,  the 
process  begins  with  preparation  of  a  statement  of  work  and  proceeds  through  contract  negotiation.  Multiple 
feedback  loops  occur  at  various  points  along  the  process  flow,  as  few  procurements  are  successfully 
completed  without  undergoing  several  iterations  and  revisions.  A  key  point  pertaining  to  the  baseline 
process  is,  nearly  all  activities  are  performed  either  by  the  Government  or  contractor,  but  not  both.  In 
contrast,  the  overall  pattern  of  the  alpha  contracting  process  flow  differs  considerably  from  that  pertaining 
to  the  baseline  (esp.  in  terms  of  process  length,  simplicity  and  collaboration),  even  though  this  latter,  alpha 
version  of  the  process  accomplishes  all  of  the  same  results  required  by  its  baseline  counterpart  above. 

A  key  point  is  that  the  alpha  contracting  process  involves  many  activities  performed  jointly  by  the 
government  and  contractor  teams.  Also,  the  alpha  contracting  approach  can  be  described  in  terms  of  an 
investment.  Both  teams  invest  the  time  and  attention  of  key  personnel  up-front  to  jointly  develop  these 
contracting  documents.  The  investment  has  objectives  that  include:  1)  improving  communications;  2) 
decreasing  the  number  of formal  RFP  iterations,  revisions  and  rework  required  to  correct 
misunderstandings,  errors  and  mistakes;  3)  reducing  the  cycle  time  (procurement  administrative  lead  time  or 
PALT)  required  for  contracting;  4)  increasing  the  level  of  trust,  openness  and  mutual  respect  between  the 
government  and  contractor  teams;  and  5)  decreasing  the  overall  cost — both  for  the  Government  and 
contractor— associated  with  the  procurement.  But  alpha  contracting  provides  a  number  of  disadvantages  as 
well.  Principal  among  them  are:  1)  increased  up-front  resources;  2)  negotiation  difficulties;  and  3) 
competitive  sourcing  complexities. 

Examination  of  alpha  contracting  as  practiced  on  the  ISOW  program  elucidates  a  number  of 
strengths  and  weaknesses  of  this  approach  to  acquisition  reform.  It  is  important  to  stress  that  although  a 
number  of  factors  make  the  JSOW  program  and  alpha  contracting  process  unique,  none  of  the  principles, 
tools  or  techniques  described  in  this  section  is  restricted  to  just  the  JSOW  program.  The  JSOW  program 
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experiences  many  benefits  (e.g.,  reduced  PALT,  improved  communication,  increased  trust)  as  well  as 
disadvantages  (e.g.,  up-front  time  commitment,  negotiation  difficulties)  of  alpha  contracting.  The  alpha 
contracting  decision  model,  originally  developed  for  the  JSOW  program,  offers  insight  and  an  analytical 
tool  for  use  by  the  contract  manager  to  assess  the  likelihood  of  alpha  contracting  success. 


CHAPTER  2  QUESTIONS 

1 .  What  is  the  principal  difference  between  the  manner  in  which  work  is  performed  in  the  baseline  (i.e., 
"traditional")  contracting  process  and  its  alpha  contracting  counterpart? 

2.  What  are  the  key  advantages  expected  through  alpha  contracting? 

3.  What  are  the  key  disadvantages  expected  through  alpha  contracting? 

4.  What  factors  from  the  alpha  contracting  decision  model  are  within  managerial  control? 
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CHAPTER  2  ANSWERS 


1 .  The  principal  difference  lies  in  the  joint  performance  of  process  activities  in  an  alpha  contracting 
approach. 

2.  Key  advantages  expected  through  alpha  contracting  include:  1)  improving  communications;  2) 
decreasing  the  number  of formal  RFP  iterations,  revisions  and  rework  required  to  correct 
misunderstandings,  errors  and  mistakes;  3)  reducing  the  cycle  time  (procurement  administrative  lead 
time  or  PALT)  required  for  contracting;  4)  increasing  the  level  of  trust,  openness  and  mutual  respect 
between  the  government  and  contractor  teams;  and  5)  decreasing  the  overall  cost — both  for  the 
Government  and  contractor — associated  with  the  procurement. 

3.  Key  disadvantages  expected  through  alpha  contracting  include:  1)  increased  up-front  resources;  2) 
negotiation  difficulties;  and  3)  competitive  sourcing  complexities. 

4.  Factors,  both  variable  and  fixed,  within  managerial  control  include  contract  type,  competition,  PMO 
commitment,  alpha  experience  and  use  of  technical  IPTs. 


Chapter  3  -  Process  Innovation 


This  chapter  addresses  process  innovation.  Here,  we  first  introduce  background  information  associated  with 
reengineering  and  draw  from  Nissen  (1996b)  to  highlight  its  key  concepts  through  discussion  of  frequently 
asked  questions.  We  focus  in  particular  on  one,  important  frequently-asked  question  pertaining  to 
differences  between  process  innovation — emerging  from  Business  Process  Reengineering  (BPR)  in  the 
Nineties — and  process  improvement — emerging  from  Total  Quality  Management  (TQM)  in  the  Eighties. 
This  discussion  is  followed  by  explanation  of  reengineering  methodologies,  techniques  and  tools  and 
provides  sufficient  detail  to  guide  direct  application  of  process  innovation  techniques  by  contract  managers. 
Specific  examples  are  then  employed  to  show  how  effective  process  redesign  is  accomplished  through 
process  innovation. 


REENGINEERING  BA  CKGROUND 

Business  Process  Reengineering  (BPR)  is  said  to  be  entering  its  second  phase  (Cypress  1994).  Through  the 
approximate  decade  of  its  first  phase,  many  disparate  methodologies  for  process  redesign  were  developed 
and  employed,  and  a  multitude  of  reengineering  books  (e.g.,  Davenport  1993,  Hammer  and  Champy  1993) 
were  published  in  the  management  press  and  widely  read.  During  this  time,  nearly  all  large  U.S. 
corporations  engaged  in  major  reengineering  projects,  and  more  than  half  of  the  annual  reports  to 
stockholders  by  Fortune  500  companies  addressed  BPR  activities  in  1994  (Hamscher  1994).  The 
Government,  including  many  military  commands,  is  also  deeply  involved  in  reengineering  today. 

In  this  first  phase,  the  rise  and  fall  of  BPR  in  the  trade  press  occurred,  as  the  topic  progressed  from 
a  state  of  perennial  hype  in  the  early  Nineties  (e.g.,  Anderson  1991,  Currid  1994,  Manager's  Notebook 
1994)  only  to  be  superseded  by  more  recent  focus  upon  topics  such  as  the  Internet,  "Intranets,"  Java,  and 
the  like  (e.g.,  Wilder  1995,  Wilder  et  al.  1995,  Marshall  and  Rodriguez  1995).  During  this  first  phase,  a 
number  of  academic  investigations  were  conducted  to  study  the  reengineering  phenomenon  (e.g.,  Stoddard 
and  Jarvenpaa  1995),  which  exposed  several  "myths"  (Davenport  and  Stoddard  1994)  in  addition  to 
outlining  many  "preconditions  for  success"  (Bashein  et  al.  1994). 

The  second  phase  promises  to  be  more  challenging  than  the  first,  particularly  as  the  reengineering 
phenomenon  continues  to  have  negligible  theoretical  basis  (Saharia  et  al.  1994).  Described  in  terms  of  a 
shift  from  "customer  value  chain"  analysis  to  a  paradigm  of  "wealth  creation  and  consumption"  (Cypress 
1994),  the  second  phase  will  require  more  knowledge,  better  understanding,  and  more  context-sensitive 
methodologies  (Nissen  1996a)  in  order  to  avoid  the  same  magnitude  (e.g.,  50-75%)  of  failure  rates  (Caron 
et  al.  1994,  Hammer  and  Champy  1993)  ascribed  to  phase  one.  This  chapter  provides  one  such  context- 
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sensitive  methodology  that  has  been  successfully  demonstrated  both  in  the  laboratory  and  through 
procurement  reengineering  projects  in  the  field. 


FREQUENTLY  ASKED  QUESTIONS 

From  its  very  likely  beginning  in  the  computer  software  industry,  the  FAQ  (i.e.,  frequently  asked  question) 
file  has  become  commonplace  in  both  business  and  academe  as  an  efficient  method  of  knowledge  transfer. 
Whether  one  is  interested  in  learning  about  new  software  (e.g.,  Java  1996),  technology  (e.g.,  PowerBrowser 
1996)  or  emerging  phenomena  such  as  electronic  commerce  (E-Commerce  1996),  FAQ  files  are  readily 
available  and  represent  an  excellent  source  of  information  with  which  to  begin  an  investigation.  That  is  the 
primary  purpose  of  this  section. 

The  "questions”  themselves  addressed  by  the  FAQs  that  follow  are  determined  primarily  through 
participation  in  a  number  of  reengineering  and  quality  newsgroups  and  summarized  in  part  through  an 
informal  poll  of  colleagues.  Although  in  no  way  intended  to  be  comprehensive,  the  "answers"  below  should 
serve  to  address  many  of  the  common  questions  pertaining  to  the  phenomenon  of  BPR.  Moreover,  by 
drawing  from  the  reengineering  literature,  these  answers  take-on  a  variety  of  perspectives  and  represent  the 
knowledge  and  practice  articulated  by  some  of  the  best  recognized  authorities  on  process  redesign.  The 
questions  and  answers  follow. 


FAQ  1  -  What  Are  the  Key  Terms  and  Concepts? 

The  reengineering  literature  represents  an  important  source  of  terms  and  concepts.  The  term  reengineering 
itself  has  been  defined  as,  ". . .  the fundamental  rethinking  and  radical  redesign  of  business  processes  to 
achieve  dramatic  improvements  in  critical,  contemporary  measures  such  as  cost,  quality,  service,  and  speed 
[emphasis  added]"  (Hammer  and  Champy  1993,  p.  32).  The  "fundamental"  nature  of  reengineering  relates 
to  questioning  assumptions;  that  is,  taking  nothing  about  a  business  or  organization  as  fixed  or  given  and 
challenging  the  appropriateness  and  existence  of  every  aspect  of  business  organization  and  operation.  This 
is  closely  related  to  the  accounting  notion  of  zero-based  budgeting  (Cheek  1977)  that  was  popular  in  the 
Seventies. 

"Radical"  redesign  refers  to  transforming  even  the  most  enduring,  stable  and  central  aspects  of  a 
process  design  configuration  and  envisioning  new  redesign  alternatives  without  limitations  or  constraints 
associated  with  a  current  design.  "Dramatic"  improvement  implies  the  level  of  performance  can  increase  by 
several  fold  (e.g.,  2x,  5x),  as  opposed  to  marginal  improvements  that  are  generally  measured  in  percentages 
(e.g.,  5%,  20%). 
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The  "measures"  from  above  are  associated  with  outputs,  in  terms  of  performance,  as  opposed  to 
inputs  to  a  business  or  organization.  One  issue  relates  to  the  fact  that  many  outputs  appear  to  be  closely 
aligned,  while  others  are  surely  oblique  and  orthogonal.  For  example,  cost  and  cycle  time  (i.e.,  speed) 
appear  to  be  closely  related  (Stalk  and  Hout  1990),  as  a  reduction  in  cycle  time  corresponds  to  a  decrease  in 
allocated  fixed  or  period  costs.  Reduced  cycle  time  can  also  enable  an  increase  in  throughput  or  production. 
However,  the  relationship  between  cost  (and  cycle  time)  and  quality  or  service  is  less  clear. 

For  example,  a  common  TQM  precept  suggests  that  improvements  in  quality  correspond  to 
decreased  cost  through  the  reduction  of  rework,  returns,  service  and  the  like.  Alternatively,  higher  quality 
output  often  requires  the  use  of  more  expensive  labor,  materials  and  technology,  which  clearly  correspond 
to  higher  costs.  Further,  superior  quality  and  service  represent  techniques  used  for  a  strategy  based  on 
differentiation  (Wiseman  1988),  which  is  not  generally  associated  with  a  cost-based  strategy  (Porter  1980). 
It  seems  clear  that  the  "success"  of  a  reengineering  project  will  necessarily  depend  upon  both  the  strategy 
being  pursued  and  the  output  being  measured. 


Table  3  Key  Reengineering  Concepts 


Topic 

Concept 

Reengineering 

Fundamental  rethinking,  radical  redesign,  process, 
dramatic  improvement,  measures,  return,  risk 

Process 

Activities,  customers,  measures,  work  ordering,  time, 
space,  beginning,  ending,  inputs,  outputs,  structure, 
action,  baseline 

Redesign 

Process  configuration,  design  flaws,  process  transformation 

Finally,  from  this  definition,  the  "process"  represents  the  central  unit  of  analysis.  The  term  process 
has  been  loosely  defined  as,  "...  a  collection  of  activities  that  takes  one  or  more  kinds  of  input  and  creates 
an  output  that  is  of  value  to  the  customer"  (Hammer  and  Champy  1993,  p.  35).  From  this  definition, 
activities ,  outputs,  customers  and  measures  represent  key  concepts  associated  with  processes.  A  similar 
definition  appears  in  Davenport  (1993,  p.  5):  "In  definitional  terms,  a  process  is  simply  a  structured, 
measured  set  of  activities  designed  to  produce  a  specified  output  for  a  particular  customer  or  market."  A 
related  definition  is  found  on  p.  2:  "A  process  is  thus  a  specific  ordering  of  work  activities  across  time  and 
place,  with  a  beginning,  an  end,  and  clearly  identified  inputs  and  outputs:  a  structure  for  action."  This  latter 
definition  helps  to  identify  additional  key  concepts,  including  ordering  of  work,  time,  space,  beginning, 
ending,  inputs,  outputs,  structure  and  action.  These  concepts  are  useful  for  building  knowledge.  Table  3 
provides  a  summaiy  of  the  key  reengineering  concepts  identified  in  this  FAQ. 
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FAQ  2  -  How  Does  BPR  Differ  from  TQM? 


Based  on  our  review  of  the  literature,  probably  the  most  distinguishing  feature  between  BPR  and  TQM  is  a 
matter  of  degree.  This  view  is  largely  consistent  with  that  expressed  in  Cole  (1994,  p.  8 1),  in  which  an 
"extraordinarily  large  number  of  similarities  between  quality  and  re-engineering"  is  asserted.  From  the  key 
terms  and  concepts  above,  the  emphasis  of  the  former  is  on  singular  and  dramatic  performance 
improvement  through  radical  process  redesign  (Barnett  1994,  Scherr  1993,  Ward  1993),  whereas  more 
continuous  and  incremental  gains  are  generally  expected  through  the  latter  (Flood  1993,  Hoffherr  et  al. 
1994,  Stein  1993).  This  view  is  echoed  in  Hammer  and  Champy  (1993,  p.  49):  whereas  . .  quality 
programs  and  reengineering  share  a  number  of  common  themes"  on  the  one  hand,  these  authors  also  state 
that  "the  two  programs  differ  fundamentally"  and  contrast  the  continuous,  incremental  nature  of  TQM  with 
discrete,  quantum  effects  of  BPR. 

The  foundations  of  BPR  are  clearly  set  in  TQM  according  to  Harrington  (1991),  and  in  building 
upon  this  work,  we  are  advised  to  ". .  .  combine  process  improvement  and  process  innovation  in  an  ongoing 
quality  program"  (Davenport  1993,  p.  14).  Alternatively,  this  same  author  describes  the  "pace  of  change"  as 
much  more  dramatic  in  a  reengineering  project.  A  similar  contrast  also  exists  in  Andrews  and  Stalick 
(1994),  but  their  eight-step  reengineering  approach  concludes  with  the  transition  to  a  CPI  (i.e.,  continuous 
process  improvement)  environment. 

However,  there  appears  to  be  nothing  in  these  expert  reengineering  methodologies  that  would 
prevent  the  gains  achievable  through  CPI  from  becoming  dramatic  (i.e.,  of  the  same  order  as  those  sought 
through  BPR).  Neither  would  radical  process  redesign  appear  to  ensure  that  improvements  will  exceed 
incremental  levels  (i.e.,  as  BPR  authors  generally  attribute  to  TQM),  or  even  be  positive  for  that  matter. 
Analogous  to  the  well  known  risk-return  relationship  captured  in  the  Capital  Asset  Pricing  Model  (Sharpe 
and  Alexander  1990),  we  are  cautioned  that  "the  risks  of  process  innovation  are  at  least  proportional  to  the 
rewards"  (Davenport  1993,  p.  15).  From  the  high  BPR  failure  rates  noted  above,  this  suggests  that 
reengineering  represents  a  more  aggressive,  but  riskier,  performance-improvement  endeavor  than  TQM. 

The  focus  of  measurement  also  differs  in  terms  of  emphasis  between  the  BPR  and  TQM  literatures. 
TQM  publications,  with  their  emphasis  on  CPI  and  Activity-Based  Costing  (Brimson  1991,  O'Guin  1991), 
appear  to  reflect  a  relatively  straightforward  extension  of  traditional  Industrial  Engineering  works  such  as 
Bailey  (1982)  or  Barnes  (1980).  Some  experts  draw  a  contrast  between  this  and  "the  new  industrial 
engineering"  (Davenport  and  Short  1990),  in  which  the  enabling  power  of  IT  is  stressed.  The  role  of  IT  in 
reengineering  represents  the  subject  of  FAQ  5  below,  but  ex-ante  process  modeling  (Curtis  et  al.  1992, 
Housel  et  al.  1993),  complexity  assessment  (Albrecht  and  Gaffney  1983,  Dreger  1989,  Kanevsky  and 
Housel  1994)  and  performance  evaluation  (Grady  1992,  Nissen  1994)  take-on  key  importance  in  BPR. 

To  reiterate,  differences  between  BPR  and  TQM  may  be  best  characterized  in  terms  of  degree 
(e.g.,  singular  vs.  continuous  activity,  dramatic  vs.  incremental  improvement  objectives,  radical  vs.  "fine 
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tuning”  process  redesign).  It  would  also  appear  that  researchers  in  each  area  may  have  much  to  gain  from 
their  counterparts  in  the  other,  and  practitioners  who  are  familiar  with  TQM  should  catch-on  quickly  to 
BPR.  This  point  highlights  one  of  the  intended  contributions  of  this  section:  to  capture  and  organize  a  major 
segment  of  the  reengineering  literature  for  the  benefit  of  researchers  and  practitioners  in  BPR,  TQM  and 
other,  relevant  disciplines  (e.g.,  Contract  Management). 


FAQ  3  -  Why  Reengineer  Organizational  Processes? 

"The  Crisis  that  Will  not  Go  Away"  is  the  title  of  Chapter  1  in  Hammer  and  Champy  (1993),  in  which  the 
authors  describe  three  forces  that  are  driving  companies  to  reengineer  organizational  processes:  1) 
customers  taking  charge,  2)  competition  intensifying  globally,  and  3)  change  perpetuating  and  increasing  in 
pace.  In  addition  to  these  external  forces  behind  reengineering,  the  authors  also  highlight  a  problem  internal 
to  business  processes  themselves  (p.  11): 

Most  companies  today — no  matter  what  business  they  are  in,  how  technologically  sophisticated  their 
product  or  service,  or  what  their  national  origin — can  trace  their  work  styles  and  organizational  roots  back 
to  the  prototypical  pin  factory  that  Adam  Smith  described  in  The  Wealth  of  Nations,  published  in  1776. 

Despite  our  common  usage  of  the  term  re-engineering ,  such  work  styles  and  organizational  roots 
do  not  appear  to  have  been  engineered  to  begin  with.  Rather,  this  suggests  organizational  processes  are 
merely  continuations  of  their  predecessors,  having  evolved  slowly  and,  in  many  cases,  changed  little 
through  the  decades  (and  centuries).  Even  if  business  processes  had  been  engineered  to  begin  with,  say  only 
ten  or  twenty  years  ago,  a  strong  case  could  still  be  made  for  their  re-engineering,  particularly  in  light  of 
"the  tool  that  has  changed  business  most  over  the  past  three  decades — information  technology"  (Davenport 
1993,  p.  5).  Not  unlike  the  advent  of  electrical  power  near  the  turn  of  the  century,  information  technology 
(IT)  can  enable  entirely  new  methods  of  performing  work. 

Further,  as  noted  above,  reengineering  has  become  very  pervasive  and  important  in  business  and 
government  alike.  The  fact  that  nearly  all  U.S.  corporations  are  undertaking  major  reengineering  projects 
implies  that  a  given  company,  which  fails  to  reengineer,  may  fall  behind  simply  by  standing  still. 
Management  is  adduced  to  simplify  and  streamline  processes  and  to  employ  "breakthrough  strategies”  to 
effect  error-free  and  world-class  levels  of  process  performance  (Harrington  1991,  p.  206).  Management  is 
also  exhorted  to  strive  for  "breakpoint  strategies”  for  renewed  competitiveness  and  competitive  dominance 
(Johansson  et  al.  1993,  p.  1 19);  here,  the  authors  defme  a  breakpoint  as  ”.  .  .  the  achievement  of  excellence 
in  one  or  more  value  metrics  where  the  marketplace  clearly  recognizes  the  advantage,  and  where  the 
ensuing  result  is  a  disproportionate  and  sustained  increase  in  the  supplier's  market  share”  (p.  1 13).  In  terms 
of  the  Competitive  Forces  Model  (Porter  1985),  not  only  does  reengineering  represent  a  threat  from  rival 
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firms  in  a  competitive  arena,  but  BPR  can  also  be  characterized  as  an  approach  to  the  attainment  of 
sustainable  competitive  advantage.  Indeed,  we  have  evidence  that  a  number  of  companies  view 
reengineering  itself  among  their  essential  core  competencies.  Such  companies  include  Cigna  (Caron  et  al. 
1994)  and  Taco  Bell  (Karlgaard  1994),  for  example. 


FAQ  4  -  What  Reengineering  Steps  Are  Required? 

Each  of  the  many  expert  reengineering  methodologies  is  comprised  of  a  somewhat  different  sequence  of 
redesign  activities  or  steps,  which  reflects  differing  emphases  across  the  various  methods.  For  example,  one 
of  the  earliest  of  these  (Rummler  and  Brache  1991)  includes  an  analytical  technique  that  helps  one  to  focus 
upon  who  (i.e.,  what  organizational  role)  is  responsible  for  what  (i.e.,  which  process  activities).  Specifically, 
it  involves  a  two-dimensional  technique  for  process  mapping,  which  builds  upon  the  standard  (one¬ 
dimensional)  flowcharting  approach  employed  in  most  methodologies.  With  this,  the  typical  flowchart 
sequencing  of  tasks  and  activities  is  extended  to  incorporate  the  second  dimension  of  organizational  role; 
that  is,  it  explicitly  links  process  activities  to  the  organizations  and  roles  responsible  for  their  execution. 

This  represents  the  approach  employed  above  to  delineate  the  baseline  and  alpha  contracting  processes 
(e.g.,  in  which  government  and  contractor  roles  are  clearly  distinguished),  for  instance. 

As  noted  above,  another  early  expert  reengineering  methodology  (Harrington  1991)  has  its  focus 
upon  process  simplification  and  streamlining.  It  involves  five  steps:  1)  organize  for  improvement;  2) 
understand  the  process;  3)  streamline;  4)  measure  and  control;  and  5)  continuous  improvement  (p.  21).  As 
should  be  apparent  from  steps  2  and  4,  this  methodology  places  considerable  emphasis  on  the  understanding 
and  measurement  of  an  existing  process  baseline,  respectively,  to  which  some  refer  as  the  "as-is"  condition 
or  configuration.  A  similar  emphasis  on  the  baseline  process  configuration  is  found  in  the  later  methodology 
of  Davenport  (1993).  This  methodology  outlines  a  sequence  of  five  high-level  activities,  which  are  listed  in 
Table  4,  and  highlights  the  importance  of  information  pertaining  to  an  existing  process  through  step  4. 

Table  4  High  Level  Reengineering  Activities _ 

Step  Activity _ _ 

1  Identifying  process  for  innovation 

2  Identifying  change  levers  (i.e.,  enabling  technologies) 

3  Developing  process  visions 

4  Understanding  and  improving  existing  processes 

_5 _ Designing  and  prototyping  the  new  process _ 

This  emphasis  provides  a  stark  contrast  with  the  methodology  of  Hammer  and  Champy  (1993),  the 
latter  of  which  involves  "starting  all  over,  starting  from  scratch"  (p.  2).  Indeed,  in  this  latter  methodology, 
analysis  of  an  existing  process  baseline  configuration  is  purposefully  excluded,  including  instead  only  a 
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high-level  understanding  of  "the  what  and  the  why,  not  the  how,  of  the  process"  (p.  131).  In  a  related  work 
(Hammer  and  Stanton  1995,  p.  19),  the  rationale  provided  is  that  M. . .  the  how  is  going  to  change  anyway  as 
a  result  of  reengineering."  The  respective  authors  refer  to  this  reengineering  approach  as  "redesign  with  a 
blank  sheet  of  paper"  (p.  131)  and  "the  proverbial  clean  slate"  (p.  4).  The  importance  of  baseline  process 
analysis  represents  a  major  issue  of  division  between  the  expert  reengineering  methodologies.  The  method 
discussed  in  this  chapter  builds  directly  upon  that  of  Davenport.  The  author  feels  the  early  practice  of 
redesigning  processes  without  first  understanding  their  baselines  contributed  substantially  to  the  high  BPR 
failure  rates  experienced  in  the  first  phase. 


Table  5  Critical  Redesign  Activities 


Phase 

Redesign  Activity 

4  -  Understanding  and  improving 

1.  Describe  the  current  process  flow 

existing  processes: 

2.  Measure  the  process  in  terms  of  the  new  process  objectives 

3.  Assess  the  process  in  terms  of  the  new  process  attributes 

4.  Identify  problems  with  or  shortcomings  of  the  process 

5.  Identify  short-term  improvements  in  the  process 

6.  Assess  current  information  technology  and  organization 

1 .  Brainstorm  design  alternatives 

5  -  Designing  and  prototyping  a 

new  process: 

2.  Assess  feasibility,  risk  and  benefit  of  design  alternatives 

3.  Select  the  preferred  process  design 

4.  Prototype  the  new  process  design 

5.  Develop  a  migration  strategy 

6.  Implement  new  organizational  structures  and  systems 

Returning  to  the  methodology  of  Davenport  (1993),  each  of  the  five  high-level  reengineering 
activities  listed  in  the  table  above  can  be  decomposed  into  a  set  of  lower-level  activities.  Focusing,  for 
example,  upon  the  elements  of  process  redesign ,  steps  four  and  five  detail  the  requisite  reengineering 
activities.  Table  5  contains  a  listing  of  the  second  level  activities  corresponding  to  steps  four  and  five. 
Through  its  inclusion  of  baseline  process  analysis  and  measurement,  this  methodology  effectively  subsumes 
that  of  Harrington  (1991)  above,  and  it  is  quite  comprehensive.  However,  although  this  present  framework 
effectively  prescribes  what  reengineering  activities  to  perform,  and  in  which  order  they  should  be 
accomplished,  it  fails  to  describe  how  to  perform  them  (i.e.,  is  not  operationalized).  This  represents  a 
common  theme  that  pervades  the  expert  reengineering  methodologies  is  addressed  directly  through  this 
chapter. 

A  subsequent  methodology  (Andrews  and  Stalick  1994)  also  outlines  a  multi-step  sequence  of 
reengineering  activities.  Unlike  its  counterparts  above,  greater  emphasis  is  placed  on  implementation,  as 
opposed  to  redesign.  Implementation  represents  a  key  stage  of  activities  in  the  reengineering  life  cycle  (see 
Guha  et  al.  1993,  Kettinger  et  al.  1995),  and  it  represents  a  major  area  of  risk  in  terms  of  BPR  success.  The 
eight  steps  are  listed  in  Table  6.  As  noted  above,  this  methodology  calls  for  transition  to  a  CPI  environment. 
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Such  institutionalization  of  process  improvement  is  also  noted  as  important  in  Davenport  (1993,  p.  14): 
"Lest  it  slide  back  down  the  slippery  slope  of  process  degradation,  [following  process  redesign]  a  firm 
should  then  pursue  a  program  of  continuous  improvement  for  the  post- innovation  process."  Again,  the 
consensus  among  reengineering  experts  suggests  that  BPR  and  TQM  are  both  compatible  and 
complementary. 


Table  6  Eight  Step  Approach 


Activity 

i 

Frame  the  project 

2 

Create  vision,  values  and  goals 

3 

Redesign  business  operations 

4 

Conduct  proof  of  concept 

5 

Plan  implementation 

6 

Get  implementation  approval 

7 

Implement  redesign 

8 

Transition  to  CPI  environment 

FAQ  5  -  What  is  the  Role  of  Information  Technology? 

As  noted  above,  information  technology  has  had  a  profound  effect  on  business  and  government  processes. 
For  a  number  of  years,  researchers  have  investigated  the  role  of  IT  in  BPR  (e.g.,  Smith  and  McKeen  1993, 
Teng  et  al.  1992),  employed  IT-based  analytical  techniques  (e.g.,  Daniels  et  al.  1991,  Dennis  et  al.  1993) 
and  developed  frameworks  to  characterize  reengineering  in  terms  of  how  IT  is  strategically  employed  (e.g., 
Ives  et  al.  1993,  Venkatraman  1994).  In  the  expert  reengineering  methodologies,  IT  is  consistently 
described  as  the  central  enabling  technology  for  process  redesign. 

For  example,  IT  is  called  the  " essential  enabler "  in  reengineering  (Hammer  and  Champy  1993,  p. 
83),  and  management  is  urged  to  "think  inductively"  (p.  84)  about  how  IT  can  be  employed  for  process 
redesign.  Such  inductive  thinking  begins  with  known  information  technologies,  such  as  those  listed  in  Table 
7  (pp.  91-101),  which  managers  use  to  identify  problems  the  technologies  can  help  to  solve.  Although  the 
authors  caution  against  an  over-reliance  on  IT  in  reengineering — colorful  terms  such  as  automating  the 
mess  and  paving  the  cowpaths  have  been  used  (Hammer  1990)  to  describe  this  situation — it  is  clearly 
central  to  their  methodology. 


Table  7  IT  Enablers _ 

Example  Enabler  (i.e.,  transformation  technology) _ 

1  Shared  databases 

2  Expert  systems 

3  Telecommunications  networks 

4  Decision  support  tools 

5  Wireless  data  communication  and  portable  computers 

6  Interactive  videodisk 
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7 

8 


Automatic  identification  and  tracking  technology 
High  performance  computing _ 


IT  also  plays  a  key  role  in  the  methodology  espoused  in  Davenport  (1993):  "...  information 
technology  [is] ...  the  most  powerful  tool  for  changing  business  to  emerge  in  the  twentieth  century." 
However,  this  author  also  acknowledges  the  importance  of  other  enabling  or  transformation  technologies  (p. 
13),  to  which  he  refers  as  "human  and  organizational  development  approaches."  This  minors  a  key  concept 
from  information  systems  that  dates  back  to  the  early  introduction  of  IT  in  business.  For  instance,  Leavitt 
(1965)  indicates  that  management  cannot  simply  introduce  IT  into  a  process.  Rather,  people,  tasks,  structure 
and  technology  must  all  be  changed  together,  or  at  least  considered.  Indeed,  Davenport  (1993,  p.  13) 
proceeds  to  state  that "...  information  technology  is  rarely  effective  without  simultaneous  human 
innovations." 

Another  view  of  IT's  role  in  process  redesign  is  provided  by  this  same  author,  in  terms  of  the  nine 
effects  that  can  be  produced  through  IT  (p.  51):  1)  automational,  2)  informational,  3)  sequential,  4)  tracking, 
5)  analytical,  6)  geographical,  7)  integrative,  8)  intellectual,  and  9)  disintermediating.  As  an  example  from 
the  emerging  phenomenon  of  electronic  commerce,  IT  is  now  employed  to  enable  consumers  to  book  airline 
flights  directly  (i.e.,  without  the  services  of  a  travel  agent)  through  the  Internet  World  Wide  Web 
(Southwest  Airlines  1996);  that  is,  one  effect  of  "Web"  technology  has  been  to  disintermediate  the  airline 
flight-booking  process. 


BPR  FAQs  Summary 

The  five  BPR  FAQs  are  listed  in  Table  8.  To  summarize  briefly,  FAQ  1  provides  the  key  terms  and 
concepts  associated  with  the  phenomenon  of  reengineering.  Central  among  these  is  the  process  as  the 
fundamental  unit  of  analysis  in  BPR  and  the  focus  upon  dramatic  performance  improvement  through  radical 
process  redesign.  FAQ  2  addresses  the  similarities  and  differences  between  BPR  and  TQM.  Despite 
differences  in  terms  of  scale,  scope  and  risk,  BPR  and  TQM  vary  predominately  in  degree  and  represent 
both  compatible  and  complementary  endeavors. 


Table  8  BPR  FAQs  Summary 


FAQ 

Summary 

FAQ  1 

Key  terms  and  concepts? 

FAQ  2 

BPR  &  TQM  differences? 

FAQ  3 

Why  reengineer? 

FAQ  4 

Reengineering  steps? 

FAQ  5 

IT  role? 

FAQ  3  follows  directly  from  FAQ  2,  in  much  the  same  manner  that  the  BPR  phenomenon  of  the 
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Nineties  followed  the  TQM  movement  that  originated  in  the  Eighties;  that  is,  by  asking  the  question,  if  we 
have  TQM,  why  reengineer  organizational  processes?  The  myriad  perspectives  circle  around  the  issue  of 
competitiveness — firms  reengineer  either  to  keep  up  with  performance  improvements  effected  at  rival  firms 
or  to  attain  competitive  advantages  of  their  own. 

FAQ  4  outlines  the  key  steps  from  a  number  of  expert  reengineering  methodologies,  from  which  a 
divisive  issue  pertains  to  the  need  for  analysis  of  an  existing  process  before  redesigning  it.  Some  experts 
note  the  importance  of  information  that  can  be  obtained  through  baseline  analysis,  whereas  others  exhort 
management  to  skip  this  step  and  pursue  a  "clean  slate"  or  "blank  sheet  of  paper"  approach.  Of  the 
methodologies  that  stress  baseline  process  analysis,  measurement  is  assigned  a  very  important  role. 
However,  the  nature  of  measurement  in  IT-enabled  process  redesign  has  a  different  emphasis  from  previous 
measurement  focuses  in  TQM. 

Finally,  FAQ  5  addresses  the  role  of  IT  in  process  redesign.  Although  IT  is  heralded  as  the  central 
enabling  technology  for  reengineering,  the  experts  caution  against  the  sole  or  excessive  reliance  on  this 
transformation  technology,  and  other  enablers  of  process  innovation  such  as  human  and  organizational 
interventions  are  adduced.  And  drawing  from  Leavitt,  we  are  reminded  that  one  cannot  simply  introduce  IT 
into  a  process  and  expect  the  kind  of  dramatic  performance  improvements  sought  through  reengineering. 
The  colorful  characterizations  "automating  the  mess"  and  "paving  the  cowpaths"  provide  vivid  reminders  of 
this  longstanding  expert  advice. 


MEASUREMENT-DRIVEN  PROCESS  INNOVATION 

In  this  section,  we  outline  a  general  redesign  process,  as  delineated  in  Figure  3,  and  use  it  to  describe  a 
practical,  measurement-driven  approach  to  process  innovation.  To  show  how  this  process  innovation  approach 
is  used,  we  draw  from  Nissen  (1998b)  and  employ  it  to  redesign  a  commercial  reengineering  case  from  the 
literature. 
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Figure  3  General  Redesign  Process 

The  sequence  of  process-redesign  activities  delineated  in  Figure  3  represents  a  blend  of  expert 
reengineering  methodologies — particularly  those  of  Andrews  and  Stalick  (1994),  Davenport  (1993),  Hammer 
and  Champy  (1993),  Harrington  (1991)  and  Johansson  et  al.  (1993)— synthesized  together  to  compose  an 
analytical  method  supporting  measurement.  The  path  through  these  steps  is  delineated  as  a  spiral  in  the  figure, 
which  represents  a  common  notation  for  evolutionary  processes  (see  Boehm  1988  for  discussion  pertaining  to 
software  engineering). 

Step  one  is  to  identify  a  target  process  for  redesign.  Next,  a  model  is  constructed  to  represent  the 
baseline  (i.e.,  “as  is”)  configuration  of  this  process,  and  configuration  measurements  then  drive  the  diagnosis  of 
process  pathologies.  The  diagnostic  results  are  used  in  turn  to  match  the  appropriate  redesign  transformations 
available  to  “treat”  pathologies  that  are  detected.  This  sequence  of  analytical  activities  leads  systematically  to 
the  generation  of  one  or  more  redesign  alternatives,  which  most  experts  argue  should  be  tested  through  some 
mechanism  (esp.  simulation)  prior  to  selection  of  a  preferred  alternative  for  implementation.  This,  baseline 
process  is  characteristic  of  first-generation  redesign  methods  and  tools,  through  which  the  three  key  intellectual 
activities — process  measurement,  pathology  diagnosis  and  transformation  matching — are  performed  manually 
at  present.  We  succinctly  expand  on  each  step  in  turn  below. 
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Identify  Process  for  Redesign 


Reengineering  experts  such  as  Davenport  (1993,  p.  27)  advise  that  “major  processes”  with  “strategic 
relevance”  should  be  targeted  for  redesign,  and  according  to  Hammer  and  Champy  (1993,  p.  122),  heuristics 
for  process  selection  include  factors  such  as  “dysfunction,”  “importance”  and  “redesign  feasibility.”  Although 
this  chapter  does  not  address  the  process-identification  step  per  se,  the  measurement-driven  redesign  approach 
discussed  in  this  section  is  oriented  toward  processes  that  involve  knowledge  application  and  information  flows 
(e.g.,  "office  work”).  This  orientation  inposes  two  requirements:  1)  that  the  process  is  stable,  and  2)  that  the 
constituent  work  activities  are  understood  well  enough  to  support  representation  in  terms  of  a  process  model. 
Thus,  if  a  process  is  not  repeatable  (e.g.,  ad-hoc  or  single-shot  work  activities)  or  participants  are  unable  to 
describe  how  the  process  is  performed  in  terms  of  its  constituent  tasks  (e.g.,  creative  work,  scientific 
discovery),  it  is  probably  inappropriate  for  measurement-driven  redesign.  As  a  note,  procurement  and 
contracting  activities  fit  the  description  of  knowledge  and  information  work  very  well. 


Develop  Process  Model 

Development  of  a  process  model  represents  a  standard  reengineering  practice  recommended  by  experts  (e.g., 
see  Davenport  1993,  Harrington  1991),  and  process  modeling  is  well  supported  by  first-generation  redesign 
tools.  We  take  advantage  of  the  fact  that  most  process  models  developed  in  practice  are  now  graphical  and 
computer-based  (see  Curtis  et  al.  1992).  A  graphical  process  model  represents  the  starting  point  for 
measurement-driven  redesign.  Figure  4  illustrates  an  example  process  model  used  for  outlining  the  associated 
techniques.  This  process  involves  four  tasks  (A,  B,  C,  D)  and  three  work  objects  (docl,  doc2,  doc3).  Each 
process  task  is  represented  by  a  node  in  the  graph,  which  is  linked  by  a  directed  edge  to  exactly  one  other  task 
in  a  simple,  linear  process  flow.  Process  attributes  are  shown  below  each  activity  node.  For  example,  Task  A 
has  three  attributes  shown:  1)  activity  name  ("Check”),  2)  role  of  the  assigned  agent  ("Check-agent”),  and  3)  IT 
resource  used  for  support  ("DBMS").  The  same  follows  for  the  other  three  process  activities. 

Redesign  Modeling  Example.  We  introduce  an  example  from  the  reengineering  literature  to  help  elucidate  the 
techniques.  The  particular  example  delineated  in  Figure  4  represents  a  snippet  of  workflow  activities  adapted 
from  the  well-known  credit  financing  process  described  by  Hammer  and  Champy  (1993,  pp.  36-39).  Here  the 
first  task  is  associated  with  performing  a  credit  check  and  is  accomplished  by  a  specialist  (denoted  by  a  specific 
role:  Check-agent)  supported  by  a  database  (DBMS).  Similarly,  another  specialist  agent  (Price-agent)  performs 
the  pricing  task  using  a  decision  support  system  (DSS),  followed  by  a  third  specialist  (Terms-agent)  who 
composes  the  appropriate  terms  and  conditions  for  financing  using  a  word  processor.  A  manager  agent  is 
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included  at  the  end  of  this  example  to  review  the  financing  package,  and  a  feedback  or  quality  loop  is  indicated 
to  denote  a  path  for  rework.  This  notation  also  indicates  that  a  separate  document  is  created  at  each  of  the  first 
three  task  nodes  (e.g.,  docl  is  created  at  Task  A;  doc2  is  created  at  Task  B)  and  that  all  three  documents  flow 
to  the  end  node  at  Task  D.  We  continue  with  this  example  throughout  the  section. 


Measure  Process  Configuration 

Process  measurement  requires  a  set  of  process  measures.  Process  measures  are  drawn  from  fields  such  as 
Statics  (e.g.,  measures  including  length,  breadth  and  depth),  Artificial  Intelligence  (e.g.,  variables  such  as 
problem  size,  parallelism/decomposability  and  feedback/cycles),  Information  Systems  (e.g.,  uses  of  IT  such  as 
support,  communication  and  automation)  and  others  (e.g.,  Coordination  Theory,  Organizational  Behavior, 
Total  Quality  Management).  Notice  these  fields  are  independent  from  reengineering-specific  methods  and 
cases.  We  stress  such  independence  as  a  knowledge  engineering  technique  to  increase  the  robustness  of 
measurement-driven  redesign.  A  detailed  description  of  this  measure-development  process  can  be  found  in 
Nissen  (1996b). 
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-  word_proc  L 

Review 
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nil 


Figure  4  Example  Process  Model 

We  should  note  this  set  of  measures  is  not  intended  to  be  complete  at  this  point.  Rather,  the  idea  is  to 
develop  a  relatively-small,  fundamental  set  and  examine  the  use  of  such  measures  to  drive  redesign  analysis, 
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particularly  in  terms  of  their  heuristic  value  for  diagnosing  process  pathologies.  Nonetheless,  the  ability  of  a 
few,  fundamental  measures  to  support  the  development  of  a  robust  analytical  capability  is  well  known.  In  the 
physical  sciences,  for  example,  nearly  all  measurement  in  physics,  engineering  and  like  disciplines  can  be 
traced  to  a  set  of  just  six,  fundamental  measures — charge,  temperature,  mass,  length,  time  and  angle  (Krantz  et 
al.  1971). 

Our  measurement  technique  requires  each  process  measure  to  be  operationalized  explicitly  using  the 
node,  edge  and  attribute  constructs  from  above.  For  instance,  process  length  is  defined  as  the  number  of  task 
nodes  connected  together  in  the  longest  path  through  the  process  model;  process  breadth  is  defined  as  the 
number  of  distinct  paths  through  the  representation;  and  so  forth.  Procedures  for  dealing  with  branch  nodes, 
cycles  and  multiple  levels  of  decomposition  are  straightforward  (e.g.,  count  the  longest  OR  branch  for 
measuring  process  length;  count  the  steps  associated  with  a  cycle  once).  Consistency  of  application  represents  a 
more  important  factor  than  selecting  any  one  procedure  over  another  (esp.  to  support  comparative  process 
analysis).  A  set  of  example  process  measures  is  presented  in  Table  9,  along  with  their  corresponding  graph- 
based  definitions. 


Table  9  Example  Process  Measures 


Measure 

Graph-Based  Definition 

Process  Length 

Number  of  nodes  in  longest  path 

Process  Breadth 

Number  of  distinct  paths 

Process  Depth 

Number  of  process  levels 

Process  Size 

Number  of  nodes  in  process  model 

Process  Feedback 

Number  of  cycles  in  graph 

Parallelism 

Process  Size  divided  by  Length 

IT  Support 

Number  of  IT-support  attributes 

IT  Communication 

Number  of  IT-communication  attributes 

IT  Automation 

Number  of  IT-automation  attributes 

Organizational  Roles 

Number  of  unique  agent  role  attributes 

Process  Handoffs 

Number  of  inter-role  edges 

Organizations 

Number  of  unique  agent  organization  attributes 

Value  Chains 

Number  of  unique  activity  Value  Chain  attributes 

Redesign  Measurement  Example.  The  credit  financing  model  from  above  is  continued  in  Figure  5,  this  time 
with  example  process  measurements  based  on  definitions  from  the  table.  For  instance,  we  see  the  process  is 
four  steps  long  (i.e.,  length  =  4),  has  one  path  through  it  (i.e.,  breadth  =1)  and  is  represented  at  a  single 
hierarchical  level  (i.e.,  depth  =1).  Process  size  (4)  accounts  for  the  four  activities,  and  the  one  feedback  loop  is 
counted  (feedback  =  1).  Interestingly,  the  parallelism  measurement  (1.00  =4/4)  represents  a  theoretical 
minimum  for  this  measure.  Notice  how  this  minimum  parallelism  (i.e.,  maximum  linearity)  reflects  the  serial 
layout  and  linear  appearance  of  the  process.  The  IT  measurements  are  taken  from  corresponding  IT  attributes 
in  the  model  (e.g.,  the  DBMS,  DSS  and  word  processor  each  count  toward  the  IT-support  value  of  3).  Using 
this  example,  we  show  how  such  process  measures  can  be  used  to  drive  the  automatic  diagnosis  of  pathologies. 
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Diagnose  Process  Pathologies 


To  develop  a  measurement-driven  diagnostic  capability,  we  introduce  a  taxonomy  of  process  pathologies  to  be 
used  for  classification  of  problems  and  shortcomings.  This  taxonomy  formalizes  some  of  the  deep 
reengineering  knowledge  required  for  process  redesign.  The  idea  is  to  use  process  configuration  measurements 
to  detect  and  classify  a  variety  of  common  process  pathologies.  The  taxonomy  is  constructed  from  the  BPR 
literature,  as  classes  and  instances  of  pathologies  are  synthesized  from  the  various  process  problems  and 
shortcomings  noted  in  the  expert  reengineering  methodologies  from  above  (e.g.,  Andrews  and  Stalick  1994, 
Davenport  1993).  The  problematic  conditions  described  in  the  many  published  redesign  cases  (e.g.,  Goldstein 
1986,  King  and  Konsynski  1990,  Stoddard  and  Meadows  1992,  Talebzadeh  et  al.  1995)  are  similarly  used  to 
organize  and  populate  the  taxonomy.  As  with  the  set  of  process  measures  above,  the  present  taxonomy  is 
intended  to  be  representative  and  extensible,  not  necessarily  complete.  The  class-level  taxonomy  of  process 
pathologies  is  presented  in  Table  10,  along  with  a  sample  instance  from  each  of  the  ten  classes. 


Measurements 

Length  =  4  Breadth  =  1  Depth  =  1 

Size  =  4  Feedback  =  1  Parallelism  =  1 .00 

IT-support  =  3  IT-communication  =  0  IT-automation  =  0 


Figure  5  Example  Process  Measurements 


Many  of  the  process  measures  from  above  can  be  used  to  detect  pathologies  set  forth  in  this 
taxonomy.  For  example,  the  first  listed  class,  “problematic  process  structure,”  refers  to  problems  stemming 
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from  the  layout  of  process  workflows.  The  corresponding  sample  instance,  “sequential  process  flows,”  is 
widely  noted  in  the  reengineering  literature  as  problematic  (e.g.,  see  Hammer  and  Champy  1993,  p.  54), 
particularly  with  the  associated  implications  in  terms  of  cycle  time  for  a  process.  Notice  from  above  the 
parallelism  measure  can  be  used  to  detect  this  process  pathology;  that  is,  a  (low)  parallelism  measurement 
quantifies  the  extent  to  which  a  process  structure  is  laid-out  in  terms  of  sequential  workflows. 

As  another  example,  the  bureaucratic  organization  is  likewise  widely  noted  in  the  reengineering  (and 
quality)  literature  as  problematic  (e.g.,  see  Hammer  and  Stanton  1995,  Flood  1993,  Hoflfherr  et  al.  1994). 
Bureaucratic  problems  are  noted  as  being  particularly  severe  in  terms  of  maintaining  a  specialized  workforce 
(i.e.,  “job  specialization”)  and  cycle-time  delays  associated  with  fragmented  work  handed-off  from  one 
functional  organization  to  another  (i.e.,  “process  friction”).  The  organizational  roles  and  process  handoffs 
measures  from  above  can  be  used  to  detect  these  respective  process  pathologies;  that  is,  a  (high)  roles 
measurement  quantifies  the  extent  to  which  an  organizational  design  reflects  job  specialization,  and  a  (high) 
handoffs  measurement  similarly  signals  fragmented  process  flows  and  the  associated  friction.  As  a  third 
example,  inadequate  IT  infrastructure  is  probably  the  most-widely  noted  process  pathology  in  the  reengineering 
literature,  as  deficiencies  in  this  area  such  as  low  IT  support  (i.e.,  “manual  processes”)  and  paper-based 
communications  have  implications  that  include  cost,  cycle  time,  quality  and  many  other  performance 
objectives.  Notice  from  above  that  the  IT  Support  and  IT  Communication  measures  can  be  used  to  detect  these 
process  pathologies. 


Table  10  Taxonomy  of  Process  Pathologies 


Pathology  Class 

Sample  Instance 

Problematic  process  structure 

Sequential  process  flows 

Bureaucratic  organization 

Job  specialization 

Fragmented  process  flows 

Process  friction 

IT  infrastructure 

Manual  process 

“Checking”  approach  to  quality 

Review-intensive  process 

Centralized  authority 

Long  decision  chains 

Under-utilized  human  potential 

Training  emphasis 

Inhibitive  leadership 

Directive  supervision 

Centralized  information 

Central  database  architecture 

Deficient  core  competency 

Low  IT  expertise 

Despite  the  promising  diagnostic  potential  seen  in  these  three  examples,  however,  not  all  pathologies 
correspond  to  measures  that  offer  the  same  level  of  diagnostic  capability.  This  is  because  the  taxonomy  and 
associated  measures  are  developed  independently  and  from  separate  sources  of  literature.  As  two  cases  in 
point,  we  have  yet  to  develop  measures  to  detect  the  “training  emphasis”  and  “directive  supervision” 
pathologies  listed  in  Table  10.  This  highlights  a  weakness  of  measurement-driven  redesign;  not  all 
heuristically-valuable  diagnostic  concepts  can  be  operationalized  in  terms  of  graph-based  measures. 


Redesign  Diagnosis  Example.  Referring  back  to  Figure  5,  we  noted  the  parallelism  measurement  (1.00) 
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reflects  the  serial  layout  and  linear  appearance  of  the  process  and  indicated  its  unit  value  represents  a 
theoretical  minimum;  that  is,  the  graph-based  measure  is  defined  such  that  a  process  cannot  have  measured 
parallelism  lower  than  unity.  This  implies  that  a  process  with  unit  parallelism  is  absolutely  linear  or  sequential, 
by  definition.  Thus,  measurement-driven  redesign  can  infer  a  process  measured  with  unit  parallelism  suffers 
from  the  pathology  “sequential  process  flows,”  an  instance  of  the  class  “problematic  process  structure.”  This 
example  is  representative  of  the  diagnostic  approach  employed  in  measurement-driven  redesign.  Inference 
based  on  other  measures  and  pathologies  is  performed  in  a  like  manner  and  can  be  accomplished  through 
straightforward,  rule-based  reasoning.  For  example,  using  Structured  English  for  clarity,  a  simple  IF-THEN 
rule  can  be  written  to  classify  this  pathology  directly. 

IF  parallelism  =  1 .00 

THEN  pathology  =  “sequential  process  flows” 

A  more  interesting  situation  arises  when  the  measured  value  for  a  dimension  does  not  correspond 
exactly  to  an  extremum,  as  would  be  the  case  with  a  parallelism  value  above  this  minimum  (e.g.,  2.00, 

3.37).  In  such  a  situation,  benchmarking  or  like  information  that  is  specific  to  a  particular  domain,  industry 
or  process  family  is  required  to  calibrate  the  measurement  gauge.  For  example,  a  measured  parallelism 
value  of  2.00  certainly  indicates  a  process  that  is  more  parallel  than  the  one  diagrammed  in  the  figure 
above,  but  for  diagnostic  purposes,  we  need  to  know  whether  this  degree  of  parallelism  is  pathological  or 
not.  This  is  where  the  domain-specific  benchmarking  information  is  employed.  In  the  case  of  credit 
financing,  for  example,  say  best  organizational  performance  in  the  industry  corresponds  to  parallelism  of 
3.33.  The  rule  from  above  can  be  extended  to  incorporate  such  benchmarking  information. 

IF  parallelism  <  3.33 

AND  process  family  =  “credit  financing” 

THEN  pathology  =  “sequential  process  flows” 

Alternatively,  the  rules  can  be  written  with  symbolic  values  such  as  “high”  and  “low,”  which  may  help 
simplify  the  discussion.  For  example,  the  rules  above  can  be  restated  as  follows. 

IF  parallelism  =  “low” 

THEN  pathology  =  “sequential  process  flows” 

IF  parallelism  <  “medium” 

AND  process  family  =  “credit  financing” 

THEN  pathology  =  “sequential  process  flows” 

Application  of  the  other  process  measurements  to  classify  pathologies  follows  a  similar  approach. 


Match  Redesign  Transformations 
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To  develop  a  measurement-driven  matching  capability,  we  introduce  a  taxonomy  of  redesign  transformations 
to  be  used  for  matching  with  pathologies.  This  taxonomy  formalizes  additional,  deep  reengineering  knowledge 
required  for  process  redesign.  The  idea  is  to  use  the  measurement-driven,  diagnostic  information  from  the  steps 
above  to  match  appropriate  transformations.  This  taxonomy  is  also  constructed  by  drawing  from  the  BPR 
literature,  as  classes  and  instances  of  redesign  transformations  are  synthesized  from  the  various  enabling 
technologies,  organizational  changes,  workflow  modifications  and  like  interventions  noted  in  the  expert 
reengineering  methodologies.  Redesign  transformations  described  in  the  many  published  BPR  cases  are 
similarly  used  to  organize  and  populate  the  taxonomy.  The  class-level  taxonomy  of  redesign  transformations  is 
presented  in  Table  1 1  along  with  a  sample  instance  from  each  of  the  seven  classes. 

The  first  class  of  redesign  transformations  is  labeled  “workflow  reconfiguration.”  This  class  pertains 
to  process  changes  that  simply  rearrange  the  layout  of  workflows;  in  other  words,  they  affect  the  sequencing  of 
process  activities  and  flow  of  work,  but  not  how  or  by  whom  the  activities  are  performed.  Process  de¬ 
linearization — rearranging  serial  process  activities  to  be  performed  more  in  parallel — represents  one  example 
of  a  transformation  from  this  class.  The  addition  of  a  “triage  step”  (see  Hammer  and  Champy  1993,  p.  55),  for 
example,  would  also  fall  into  this  class.  Similarly,  a  shared  database  system  represents  an  instance  from  the  IT 
transformation  class,  as  are  decision  support  systems,  local  area  networks  and  like  information  systems  and 
their  associated  infrastructure.  In  fact,  most  of  the  IT-based  enabling  technologies  cited  throughout  the 
reengineering  literature  (e.g.,  see  Hammer  and  Champy  1993,  pp.  92-99)  would  fall  into  this  second  class  of 
transformations.  Other  transformations,  such  as  organizational  design  changes  associated  with  instituting  a  case 
manager  position,  follow  the  same  class-instance  structure  of  the  taxonomy. 


Table  11  Taxonomy  of  Redesign  Transformations 


Transformation  Class 

Sample  Instance 

Workflow  reconfiguration 

Process  de-linearization 

Information  technology 

Shared  database  system 

Organizational  design 

Case  manager 

Human  resource 

Team-based  compensation 

Information  availability 

Informate  agents 

Inter-organizational  alliance 

Supplier-managed  inventory 

Management  &  culture 

Employee  stock  ownership 

Redesign  Matching  Example.  Referring  again  to  the  measures  presented  in  Figure  5,  we  noted  the  unit  (i.e., 
“low”)  parallelism  measurement  drives  inference  to  diagnose  the  pathology  “sequential  process  flows.”  As 
above,  a  straightforward  rule  can  be  written  to  match  this  pathology  with  an  appropriate  transformation.  The 
relevant  diagnostic  measurement  is  noted  next  to  this  rule  for  reference. 
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IF  pathology  =  “sequential  process  flows” 

THEN  redesign  transformation  =  “de-linearization’ 


(parallelism  =  1 .00  or  “low”) 


Other  pathologies  and  recommended  redesign  transformations  for  the  credit  financing  case  follow  from  similar 
rules.  It  is  interesting  to  note  several  of  these  latter  transformations  correspond  to  the  redesign  interventions 
actually  recommended  and  employed  in  the  credit  financing  case  described  by  Hammer  and  Champy.  For 
example,  the  “case  manager”  recommendation  can  be  obtained  directly  from  measurement-driven  redesign. 

IF  pathology  =  “job  specialization”  (roles  =  4  or  “high”) 

AND  pathology  =  “process  friction”  (handoffs  =  3  or  “high”) 

THEN  redesign  transformation  =  “case  manager” 

Matching  of  the  other  pathologies  to  redesign  transformations  follows  a  similar  approach. 


Generate,  Test  and  Select  Redesign  Alternatives 

Regarding  generation  of  alternatives,  each  redesign  transformation  from  above  is  tantamount  to  a  consultant¬ 
like  recommendation  for  process  change.  Applying  one  or  more  of  the  redesign  transformations  matched  by 
measurement-driven  redesign  produces  the  corresponding  alternative  (i.e.,  “to  be”)  process  models  intended  to 
improve  process  performance.  For  example,  a  redesign  alternative  generated  by  measurement-driven  redesign 
for  credit  financing  is  shown  in  Figure  6  as  the  result  of  applying  the  “de-linearize”  transformation  to  tasks  B 
and  C  (serially  independent).  We  should  note  this,  cycle-time  reducing  transformation  is  not  even  mentioned  in 
the  case. 

Simulation-based  testing  is  useful  to  compare  the  relative  performance  associated  with  multiple, 
competing  redesign  alternatives — prior  to  implementation — and  it  represents  a  powerful  analytical  method 
that  is  particularly  useful  for  evaluating  alternatives  that  are  either  too  expensive  or  time-consuming  to  test 
physically  (Law  and  Kelton  1982).  Simulation  represents  a  well-established  area  of  study,  supported  by  an 
abundance  of  methods,  tools  and  experience.  When  care  is  taken  to  validate  simulation  models  against  the 
performance  of  their  physical  counterparts  in  operational  processes,  the  results  can  be  quite  dependable  (see 
Bitauld  et  al.  1997,  van  Mael  1993,  van  Mael  et  al.  1995).  An  even  greater  abundance  of  decision  methods, 
tools  and  experience  is  available  to  guide  and  support  the  selection  of  a  preferred  redesign  from  multiple 
alternatives,  the  final  redesign  step. 

To  summarize,  through  measurement-driven  redesign,  we  capture  and  formalize  deep  reengineering 
knowledge  and  specialized  redesign  expertise  and  develop  a  second-generation  BPR  tool  to  automate  three, 
time-consuming  intellectual  redesign  activities— process  measurement,  pathology  diagnosis  and  transformation 
matching.  In  this  section,  we  see  how  measurement-driven  redesign  applies  its  knowledge  and  expertise  to 
redesign  a  credit  financing  process  and  note  that  its  generated  recommendations  match  several  of  the  redesign 
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transformations  actually  employed  in  the  case.  Measurement-driven  redesign  even  recommends  promising 
transformations  (e.g.,  de-linearizing  sequential  activities)  not  mentioned  in  the  case.  This  highlights  some  of  the 
power  and  potential  of  the  approach. 


Length  =  3  Breadth  =  2  Depth  =  1 

Size  =  4  Feedback  =  1  Parallelism  =  1.33 

IT-support  =  3  IT-communication  =  0  IT-automation  =  0 

Figure  6  Redesign  Alternative  (“to  be”)  Model 


PROCUREMENT  PROCESS  REDESIGN 

This  section  examines  use  of  the  process  innovation  approach  above  to  redesign  procurement  processes. 
Specifically,  we  draw  from  Nissen  (1998b)  to  show  how  innovation  can  be  employed  for  a  process  frequently 
encountered  in  acquisition:  Justification  and  Approval. 


Justification  and  Approval  Process 

We  begin  with  Justification  and  Approval  (J&A),  a  relatively  small  but  complex  procurement  process  that  is 
insightful  for  discussion.  The  J&A  process  is  involved  with  all  sole-source  or  "other  than  full  and  open 
competition"  procurements  in  the  Government,  and  it  is  expressly  required  by  regulation.  Although  not  a 
large  process,  it  is  quite  complex  and  has  been  identified  by  senior  procurement  officials  as  particularly 
important  and  dysfunctional.  Recall  that  factors  such  as  importance  and  dysfunction  are  noted  above  as 
useful  heuristics  for  identifying  processes  to  be  redesigned.  A  level- 1  baseline  process  model  for  J&A  is 
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presented  in  Figure  7. 


Customer 
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J&A  doc  CS  Approvals 
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-  Level  (1) 
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-  Agent(CS) 

-  Cardinality(l) 

-  Org( Procurement) 

-  lnputs(Stub,  rqmts) 

-  Outputs{J&A_draft) 

-  IT_Tools(NIL) 

-  Communication(Paper) 


File 


Figure  7  J&A  Level-1  Baseline  Process  Model 

At  this  top  level,  the  process  is  comprised  of  five  tasks:  1)  Customer  assistance,  2)  J&A 
documentation,  3)  Contract  Specialist  (CS)  assignment,  4)  Approvals,  and  5)  J&A  filing.  Notice  the  process 
is  entirely  sequential,  with  each  activity  following  a  single  predecessor  in  linear  fashion.  A  feedback  or 
quality  loop  is  used  to  represent  rework  that  results  from  disapproval  of  a  J&A  documentation  package. 
Several  familiar  process  attributes  (e.g.,  agent,  organization,  IT  tools)  and  values  are  listed  below  the  “J&A 
doc”  task  in  the  figure,  for  instance.  To  avoid  cluttering  this  particular  diagram,  we  have  omitted 
corresponding  attributes  for  the  other  process  activities  from  Figure  7.  These  attributes  correspond  to  those 
discussed  in  the  context  of  the  credit  financing  case.  The  figure  also  includes  some  measurement-driven 
redesign  extensions  (e.g.,  inputs,  outputs,  communication)  to  the  set  discussed  above.  In  this  representation, 
the  circle  icons  represent  atomic  tasks  that  are  not  decomposable,  and  the  square  icons  represent 
decomposable  workflows  that  are  comprised  of  lower-level  subprocesses.  Both  the  customer  assistance  and 
the  approvals  tasks  are  comprised  of  lower-level  workflows  in  this  manner.  In  fact,  the  approvals  workflow 
has  two  hierarchical  levels  beneath  it  (for  a  total  process  depth  of  3  levels;  not  shown). 
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Figure  8  J&A  Level-2  Baseline  Process  Model  -  Approvals 

Figure  8  depicts  the  level-2  baseline  process  model  comprising  the  approvals  workflow.  Here  the 
figure  represents  an  annotated  “screendump”  from  a  different  modeling  tool.  Here,  the  hexagonal  nodes 
represent  starting  and  ending  points  for  feedback  loops,  which  differs  somewhat  from  the  notation  in  Figure 
7  above.  As  can  be  seen  from  the  level-2  approvals  diagram,  the  workflow  consists  of  four,  sequential  J&A 
reviews.  Briefly,  the  J&A  documentation  is  first  reviewed  by  an  agent  from  the  Legal  Department,  who  may 
or  may  not  approve  it.  If  approved,  the  J&A  package  proceeds  to  the  next  review,  whereas  in  the  latter  case 
it  is  returned  for  rework.  After  Legal  approval,  the  J&A  package  is  reviewed  by  the  Contracting  Officer 
(KO),  who  similarly  may  either  approve  it  or  remand  it  for  rework.  We  note  the  review  by  one  agent  (e.g., 
the  KO)  is  not  dependent  upon  the  results  of  the  preceding  review  (e.g.,  Legal).  The  linear  review  process 
continues  in  this  fashion  with  the  J&A  package  then  sent  for  review  by  competition  advocates  from  the 
requiring  activity  (RACA)  and  procurement  activity  (PACA).  The  RACA  and  PACA  roles  emerged  from 
the  Competition  in  Contracting  Act  (CICA),  and  assigned  personnel  perform  an  important  function  by 
scrutinizing  J&As  and  promoting  competition.  A  conditional  branch  in  the  workflow  demarcates  an 
additional  process  step  required  to  obtain  senior  management  approval  of  J&As  above  a  certain  dollar 
threshold. 

Measurement,  Diagnosis  and  Matching 
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Some  of  the  more  illustrative  configuration  measurements  are  summarized  in  Table  12  for  the  J&A  process 
along  with  the  corresponding  diagnoses.  Note  the  “small”  size  does  not  represent  a  pathology  per  se.  The 
process  size  (31),  organizational  roles  (7)  and  parallelism  (1.00)  measurements  are  computed  in  the  same 
manner  described  for  the  credit  financing  example,  as  are  the  familiar  length  (31),  breadth  (1),  depth  (3)  and 
other  parameters  (not  shown).  And  the  roles  measurement  (7)  receives  the  same  interpretation  (i.e., 
narrowly-defined  job  scope)  as  above  in  the  credit  financing  case.  Alternatively,  the  three  IT  "fractions” 
differ  somewhat  from  the  corresponding  IT  “counts”  analyzed  in  the  credit  financing  case.  Specifically, 
these  fractional  measurements  are  calculated  by  dividing  process-size  (31)  into  the  counts  for  IT-based 
support  (1),  communication  (0)  and  automation  (0),  respectively.  Such  scaling  (e.g.,  dividing  IT  counts  by 
process  size)  improves  inter-process  comparability  and  makes  the  measurement-driven  method  more  robust 
to  differences  in  process  size. 


Table  12  J&A  Configuration  Measurements  and  Diagnoses 


Configuration  Measure 

Value 

Diagnosis 

Process  Size 

31 

Small  process 

Organizational  roles 

7 

Job  specialization 

Parallelism 

1.00* 

Sequential  process  flows 

IT-Support  fraction 

0.03 

Manual  process 

IT-Communication  fraction 

0.00* 

Paper-based  process 

IT-Automation  fraction 

0.00* 

Labor-intensive  process 

Feedback  fraction 

0.35 

Review-intensive  process 

Handoffs  fraction 

0.58 

Process  friction 

*  denotes  theoretical  extremum  for  a  measure 


For  instance,  the  same  measurement-driven  redesign  rules  that  are  used  for  diagnosing  the  J&A 
process  (i.e.,  with  size  of  31)  apply  equally  well  to  Major  Procurement  (e.g.,  with  over  800  modeled  process 
tasks).  Note  the  values  for  parallelism  and  these  measured  IT  fractions  are  at  or  near  their  theoretical 
minima  (extrema  are  denoted  by  asterisks  in  the  table).  This  indicates  the  baseline  J&A  process 
configuration  is  not  only  sequential  but  highly  manual,  paper-based  and  labor-intensive  as  well.  Likewise, 
the  feedback  fraction  (0.35)  highlights  the  review-intensive  nature  of  the  process,  and  the  handoff  fraction 
(0.58)  similarly  underscores  the  substantial  process  friction. 

The  eight  recommended  redesign  alternatives  are  summarized  in  Table  13  along  with  the  matching 
pathologies  for  reference.  Notice  several  of  these  pathology-transformation  combinations  correspond  to 
similar  measurement-driven  redesigns  discussed  in  the  context  of  credit  financing.  For  example,  the 
pathology  “sequential  process  flows”  is  matched  with  the  de-linearize  redesign  transformation.  Notice  in  the 
present  instance  the  de-linearization  transformation  is  targeted  explicitly  toward  the  approvals  workflow. 
This  targeting  results  from  the  high  feedback-fraction  measurement,  which  helps  measurement-driven 
redesign  to  focus  on  the  approvals  portion  of  the  process. 

The  de-linearization  transformation  is  used  in  turn  to  generate  two,  similar  but  distinct  redesign 
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alternatives:  1)  concurrent  reviews,  and  2)  joint  reviews.  The  first  alternative  involves  asynchronous 
reviews  conducted  in  parallel  as  opposed  to  serially  (e.g.,  each  reviewer  receives  an  identical  J&A 
documentation  package  from  the  CS),  whereas  the  second  alternative  requires  contemporaneous  (i.e.,  joint) 
meetings  by  the  participants  to  review  the  J&A  documentation.  Likewise,  low  IT  support  for  a  frictional, 
document-based  process  drives  the  same  shared  database  transformation  implemented  in  the  credit 
financing  example,  this  time  in  conjunction  with  electronic  mail.  The  corresponding  redesign  alternative 
(number  3)  is  labeled  “e-document  infrastructure”  to  denote  the  non-paper-based  nature  of  the  proposed 
process  change.  The  fourth  redesign  alternative,  “contracts  workflow  system,”  is  generated  from  a  similar 
but  more-sophisticated  transformation  to  automate  “routine  workflows”  (see  Georgakopoulos  et  al.  1995) 
associated  with  contracts  work.  This  latter  measurement-driven  redesign  recommendation  is  driven  by  the 
same  pathologies  noted  above,  with  the  addition  of  “labor-intensive  process”  (i.e.,  negligible  IT 
automation).  The  reader  may  notice  this  workflow  redesign  reflects  exactly  the  kind  of  technology 
embedded  within  the  DoD  Standard  Procurement  System  (SPS).  Thus,  the  results  stemming  from  redesign 
of  this  J&A  process  may  also  have  implications  for  processes  supported  by  SPS. 

Continuing  down  the  table  entries,  we  find  the  same  case  manager  transformation  (i.e.,  from  the 
credit  financing  example)  matched  consistently  with  the  job  specialization  and  process  friction  pathologies. 
This  redesign  transformation  is  used  to  generate  a  “J&A  case  team”  redesign,  which  envisions  an  integrated 
team  (e.g.,  including  the  CS,  KO,  RACA,  PACA  and  legal  representative)  working  together  through  the 
entire  J&A  process.  The  job  specialization  pathology  also  matches  with  three  empowerment 
transformations — two  oriented  toward  expanding  CS  responsibilities  and  one  that  includes  enlarging  the 
KO  job  scope.  Basically,  these  eight  redesign  alternatives  result  from  the  same  application  of  diagnostic 
measures,  knowledge  taxonomies  and  rule-based  inference  that  are  described  in  terms  of  the  credit 
financing  example,  except  they  are  applied  here  in  the  field  to  an  operational  J&A  process  from  the  military 
procurement  domain.  We  now  elaborate  further  on  the  redesign  results. 


Redesign  Results 

We  noted  above  that  simulation  is  used  to  assess  the  relative  performance  of  redesign  alternatives.  To  help 
reduce  the  number  of  simulation  models  required,  we  enlist  the  support  of  process  experts  to  refine  the  set 
of  redesign  alternatives  generated  above.  Combining  their  in-depth  process  knowledge  with  evaluation 
criteria  such  as  process  feasibility,  implementability  and  projected  benefit,  this  team  identifies  a  subset  of 
the  redesign  alternatives  from  above  as  "preferred”  (emphasized  by  bold  print  in  Table  13).  For  example, 
the  experts  predict  the  joint  reviews  alternative  (number  2)  will  produce  greater  benefit  than  its  concurrent- 
reviews  counterpart  (number  1).  They  express  a  similar  preference  for  the  contracts  workflow  system 
(number  4)  over  its  e-document  counterpart  (number  3).  The  experts  also  assess  these  first  four  redesign 
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alternatives  to  be  both  feasible  and  implementable  in  the  current  organization  (Project  Reviews  1995). 


Table  13  Redesign  Alternatives 


Diagnosed  Pathology 

Recommended  Transformation 

Redesign  Alternative 

Sequential  process  flows  +  review¬ 
intensive  process 

De-linearize  (approvals) 

1 .  Concurrent  reviews 

Sequential  process  flows  +  review¬ 
intensive  process 

De-linearize  (approvals) 

2.  Joint  reviews 

Manual  process  +  paper-based 
process  +  process  friction 

Shared  database  +  e-mail 

3.  E-document  infrastructure 

Manual  process  +  paper-based 
process  +  process  friction  +  labor- 
intensive  process 

Workflow  management  system 

4.  Contracts  workflow  system 

Job  specialization  +  process  friction 

Case  manager 

5.  J&A  case  team 

Job  specialization 

Empowerment  (3) 

6-8.  CS  and  KO  job  enlargement 

bold  denotes  “preferred”  redesign  alternative 


In  contrast,  although  the  experts  can  foresee  good  potential  for  the  case  manager  and 
empowerment  alternatives  (numbers  5-8),  and  they  similarly  view  them  as  feasible  transformations,  their 
judgment  is  the  required  organizational  changes  are  not  implementable  at  the  present  time.  As  a  result  of  the 
expert  analysis,  we  simulate  only  the  two,  preferred  redesign  alternatives  (i.e.,  the  subset  selected  by  the 
experts).  This  approach  is  actually  recommended  by  the  process  managers  as  a  way  to  expedite  the  analysis, 
and  it  may  represent  a  prudent  use  of  analytical  resources  in  other  reengineering  engagements  as  well. 

For  this  analysis,  the  simulated  cost  and  cycle  time  of  each  redesign  alternative  is  compared  with 
that  of  the  J&A  process  baseline.  The  baseline  J&A  simulation  model  is  first  validated  using  recent 
performance  data  (e.g.,  process  cost,  cycle  time,  throughput),  reviewed  by  process  experts  and  subjected  to 
other  validation  techniques.  For  example,  construction  of  the  simulation  model  itself  is  homomorphic  (see 
Roberts  1979)  to  the  baseline  measurement-driven  redesign  process  model;  that  is,  each  of  the  same  agents, 
tasks  and  resources  used  to  represent  the  baseline  J&A  process  diagrammed  above  is  also  used  in  the 
dynamic  simulation  model. 

A  commercial  software  package  (WITNESS)  is  employed  to  simulate  the  performance  of  the  J&A 
baseline  and  each  "preferred"  redesign  alternative.  In  this  analysis,  activity-based  cost  and  cycle  time  are 
used  to  measure  process  performance.  Other  measures  such  as  throughput,  rework,  agent-utilization  and  the 
like  are  also  informative,  but  cost  and  cycle  time  are  the  output  measures  of  interest  here.  This  is  consistent 
with  a  similar  emphasis  on  cost  and  cycle  time  found  in  the  reengineering  literature.  To  compare  the  relative 
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performance  of  the  redesign  alternatives,  each  simulated  process  is  run  for  the  equivalent  of  one,  steady- 
state  fiscal  year;  that  is,  the  dynamic  model  is  allowed  to  "warm  up"  and  stabilize  before  simulated 
performance  for  the  fiscal  year  is  measured. 


Table  14  Redesign  Simulation  Results 


Cost 

Cycle  Time 

Redesign  Alternative 

Reduction 

Reduction 

Joint  Reviews 

28% 

67%* 

Contracts  Workflow  System 

nil 

67%* 

*  denotes  performance-doubling 


Simulation  results  for  the  J&A  process  are  summarized  in  Table  14  for  reference.  From  the  table 
entries,  we  see  the  joint-reviews  transformation  results  in  a  28%  (simulated)  cost  improvement  over  the 
baseline,  primarily  due  to  a  reduction  in  rework  enabled  by  the  joint-meeting  format.  More  impressive,  this 
redesign  alternative  results  in  a  two-thirds  reduction  in  cycle  time  for  performance  of  the  J&A  process.  The 
reduction  in  rework  contributes  in  part  to  this  result,  but  the  decreased  cycle  time  is  driven  primarily  by 
concurrent  review  (i.e.,  parallel  vs.  sequential  performance).  The  asterisks  in  the  table  are  used  to  denote 
results  that  exceed  the  performance-doubling  threshold  established  for  the  field  study.  This  threshold  is 
intended  to  differentiate  between  "dramatic"  performance  improvements  (i.e.,  as  sought  through  BPR)  and 
"incremental"  gains  (i.e.,  reflecting  more  of  a  TQM  approach). 

Interestingly  (and  coincidentally),  the  contracts  workflow  system  matches  this  two-thirds  reduction 
in  cycle  time,  but  it  produces  negligible  savings  in  terms  of  cost.  The  reduced  friction  associated  with 
eliminating  J&A  paper  handoffs  (e.g.,  work  sitting  in  in-boxes  and  out-boxes,  awaiting  assignment,  pausing 
for  review  and  approval)  contributes  toward  this  dramatic  cycle-time  improvement,  as  does  the  decreased 
transportation  time  between  process  activities.  The  absence  of  cost  savings  is  attributable  to  the  fact  that  the 
process  tasks  themselves  remain  fundamentally  unchanged  with  the  workflow  system;  that  is,  the  J&A  work 
itself  remains  the  same,  as  only  the  interface  and  communication  between  activities  are  automated  through 
the  workflow  management  system.  We  noted  above  this  effect  has  been  colorfully  referred  to  as  "paving  the 
cowpaths"  in  the  reengineering  literature  (Hammer  1990). 

It  is  also  important  to  note  these  two  redesign  alternatives  are  generated  independently.  The 
analysis  recommends  each  transformation  be  applied  to  redesign  the  J&A  process  individually.  However, 
this  does  not  prohibit  applying  them  in  combination.  Indeed,  a  manager  can  elect  to  combine  these  two  (or 
any  other)  transformations  and  attempt  to  produce  even  more  dramatic  gains  in  performance.  However, 
each  such  combination  requires  a  separate  simulation,  for  the  individual  results  (esp.  cycle  time)  are 
unlikely  to  be  additive. 
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CHAPTER  3  SUMMARY 


Drawing  from  the  BPR  FAQS,  nearly  all  large  U.S.  corporations  have  engaged  in  major  reengineering 
projects,  and  the  Government,  including  many  military  commands,  is  also  deeply  involved  in  reengineering 
today.  The  term  reengineering  itself  has  been  defined  as,  the  fundamental  rethinking  and  radical  redesign 
of  business  processes  to  achieve  dramatic  improvements  in  critical,  contemporary  measures  such  as  cost, 
quality,  service,  and  speed.  Probably  the  most  distinguishing  feature  between  BPR  and  TQM  is  a  matter  of 
degree.  The  emphasis  of  the  former  is  on  singular  and  dramatic  performance  improvement  through  radical 
process  redesign,  whereas  more  continuous  and  incremental  gains  are  generally  expected  through  the  latter. 
The  primary  reason  most  firms  reengineer  is  either  to  keep  up  with  performance  improvements  effected  at 
rival  firms  or  to  attain  competitive  advantages  of  their  own.  Reengineering  methodologies  differ  with 
respect  to  analysis  of  an  existing  process  baseline  configuration  and  in  many  other  ways.  But  of  the 
methodologies  that  stress  baseline  process  analysis,  measurement  is  assigned  a  very  important  role.  Finally, 
although  IT  is  heralded  as  the  central  enabling  technology  for  reengineering,  the  experts  caution  against  the 
sole  or  excessive  reliance  on  this  transformation  technology,  and  other  enablers  of  process  innovation  such 
as  human  and  organizational  interventions  are  adduced. 

Process  innovation  is  modeled  as  a  spiral  process  comprised  of  eight  steps:  1)  identify  a  target 
process  for  redesign;  2)  construct  a  baseline  process  model;  3)  obtain  configuration  measurements;  4  diagnose 
process  pathologies;  5)  match  appropriate  redesign  transformations;  6)  generate  redesign  alternatives;  7)  test 
through  simulation;  and  8)  select  a  preferred  alternative  for  implementation.  These  steps  are  included  in  the 
measurement-driven  redesign  approach  used  above  to  redesign  a  commercial  process  from  the  literature  and  a 
procurement  process  in  the  field.  This  represents  a  systematic  approach  to  process  redesign,  which  is  capable 
of  matching  the  performance  of  BPR  consultants — as  in  the  credit  financing  case — and  effecting  dramatic  cost 
and  cycle-time  performance  improvements  in  procurement  processes — as  with  the  J&A  process. 


CHAPTER  3  QUESTIONS 

1 .  In  what  respects  does  business  process  reengineering  differ  from  total  quality  management? 

2.  What  has  been  considered  the  most  powerful  technology  available  to  enable  process  innovation? 

3.  Through  which  techniques  is  reengineering  knowledge  captured  for  use  through  measurement-driven 
redesign? 
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CHAPTER  3  ANSWERS 


1.  Despite  differences  in  terms  of  scale,  scope  and  risk,  BPR  and  TQM  vary  predominately  in  degree  and 
represent  both  compatible  and  complementary  endeavors. 

2.  Information  technology  is  widely  regarded  as  the  most  powerful  enabler  of  radical  process  redesign  and 
dramatic  performance  improvement. 

3.  Primary  techniques  for  reengineering  knowledge  capture  include  the  use  of  measurements, 
taxonomies — one  for  process  pathologies,  another  for  redesign  transformations — and  rules. 
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Chapter  4  -  Contracting  Innovation 


In  this  final  chapter,  we  integrate  the  concepts  and  techniques  presented  above  to  innovate  the  contracting 
process.  Indeed,  employing  the  process  innovation  approach  from  above,  we  further  innovate  a  contracting 
process  that  has  already  been  substantially  improved  through  alpha  contracting.  Drawing  from  our 
discussion  above,  this  example  pertains  to  the  JSOW  alpha  contracting  process.  The  JSOW  example  is  used 
not  only  to  explain  and  demonstrate  the  application  of  process  innovation  techniques  from  above,  but  to 
also  develop  a  process  vision  for  future  contracting  innovations.  To  begin  this  discussion,  first  we  draw 
again  fromNissen  (1998a)  to  briefly  describe  the  alpha  contracting  process  and  delineate  its  workflow. 
Then  we  apply  redesign  techniques  to  further  innovate  the  process  and  assess  strengths  and  weaknesses  of 
each  process  redesign  alternative.  The  chapter  concludes  with  a  summary. 


ALPHA  CONTRACTING  INNOVATION  EXAMPLE 

Government  Joint  Contractor 


The  JSOW  program  described  above  represents  a  major  (e.g.,  ACAT  ID)  weapon  system.  Although  we 
noted  above  the  techniques  and  benefits  of  alpha  contracting  are  in  no  way  limited  to  such  large,  complex 
procurements,  examination  of  this  major  contracting  case  highlights  many  additional  considerations  that 
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benefit  the  present  discussion.  The  JSOW  process  is  also  useful  to  demonstrate  how  further  innovation  is 
possible  with  an  alpha  contracting  process. 

For  reference,  the  JSOW  alpha  contracting  process  flow  is  delineated  in  Figure  9.  Notice  this  process  flow 
bears  a  very  close  resemblance  to  the  general  alpha  contracting  flow  presented  in  Figure  2. 

For  clarity,  and  because  the  JSOW  program  operates  strictly  within  a  sole-source  environment,  we 
omit  the  process  steps  pertaining  to  synopsis  by  the  Government  and  expression  of  interest  by  the 
contractor.  But  notice  an  additional  step  for  alpha  planning  that  precedes  the  "develop  proposal"  activity. 
To  help  organize  and  streamline  the  alpha  contracting  process,  the  JSOW  team  divides  the  SOW/RFP  into 
areas  of  responsibility  and  cost  accounts  that  are  assigned  to  specific  individuals,  from  both  sides  of  the 
contract,  for  development.  For  example,  the  SOW/RFP  associated  with  the  air  vehicle  may  be  assigned  to 
the  program  managers'  deputies  (i.e.,  for  both  the  Government  and  contractor  teams)  to  manage  in  total. 
Further,  each  major  cost  account  associated  with  the  air  vehicle  (e.g.,  engineering,  manufacturing,  logistics, 
materiel)  is  assigned  to  lead  individuals,  from  both  sides,  to  develop.  With  this,  we  generally  have 
engineering  cost  account  managers  working  together  on  the  engineering  proposal  estimates,  manufacturing 
cost  account  managers  working  together  on  the  manufacturing  proposal  estimates,  and  so  forth. 


Baseline  Process  Model 

Using  the  notation  introduced  in  Chapter  3,  the  JSOW  alpha  contracting  process  is  modeled  for  redesign 
analysis  in  Figure  10.  As  in  Figure  9  above,  the  process  begins  with  SOW  preparation  (activity  node  labeled 
"A"  for  reference),  but  for  clarity,  the  flow  depicted  in  Figure  10  stops  with  the  negotiation  step  (activity 
node  labeled  "G"  for  reference).  The  attributes  listed  beneath  each  activity  node  indicate  the  following  four 
properties:  1)  name  (e.g.,  SOW  development)  of  the  process  activity,  2)  role  (e.g.,  technical  work)  and 
organization  (e.g.,  contractor)  responsible  for  performance  of  the  activity,  3)  tools  (e.g.,  word  processor) 
used  to  support  the  activity,  and  4)  media  (e.g.,  paper  documents)  used  for  communication  and  flow  of  work 
between  activities.  A  fifth  attribute  for  automation  (e.g.,  through  IT)  is  also  included,  but  the  alpha 
contracting  process  involves  no  such  automation  in  its  present  state.  Continuing  with  the  first,  SOW 
preparation  activity  (labeled  "A"),  it  principally  involves  technical  work  (denoted  by  the  label  "T"),  and  one 
can  observe  both  the  Government  and  contractor  (labeled  ”G  &  C")  jointly  perform  this  task  using  a  word 
processor  (labeled  "WP")  for  support.  Communications  are  effected  using  two  media:  paper  for 
documentation  and  meetings  for  joint  discussion.  The  same  basic  attributes  can  also  be  observed  for  the 
subsequent  draft-RFP  (node  "B"),  alpha-planning  (node  "C")  and  proposal-development  steps  (node  "D"). 
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Figure  10  JSOW  Alpha  Contracting  Process  Model 

Notice  two  feedback  loops  flowing  back  to  the  draft-RFP  activity  (node  "B").  The  first  one, 
stemming  from  node  "C,"  reflects  the  fact  that  a  draft  RFP  may  not  be  approved  when  reviewed  by  the 
Government  and  contractor  teams  (see  Figure  9),  in  which  case  the  draft  RFP  is  remanded  to  the  alpha 
contracting  IPTs  for  rework.  The  second  one,  stemming  from  node  "D,M  similarly  reflects  the  fact  that  a 
draft  proposal  may  not  be  approved  when  reviewed  by  the  respective  teams  noted  in  Figure  9,  and  hence 
may  likewise  be  remanded  to  the  alpha  contracting  IPTs  for  rework.  Although  not  shown  in  the  figure  to 
avoid  cluttering  the  diagram,  clearly,  such  feedback  loops  can  also  extend  back  to  the  SOW  preparation 
activity.  For  instance,  oftentimes,  technical  scope  must  be  reduced  for  a  program  to  fit  within  budget 
constraints. 

As  delineated  above,  the  process  flow  splits  after  node  "D,"  as  the  Government  and  contractor 
organizations  separately  develop  their  business  clearances  and  establish  negotiation  targets,  respectively. 
Little  in  the  way  of  support  tools  is  used  to  support  these  steps,  as  they  consist  principally  of  face-to-face 
meetings  with  the  respective  management  groups  (e.g.,  through  presentations).  The  process  flow  converges 
again  through  the  negotiation  activity  (node  "G")>  which  is  performed  jointly  by  the  Government  and 
contractor.  As  with  some  preceding  activities,  paper  is  used  to  document  the  final  negotiation  results,  and 
bargaining  is  generally  conducted  in  a  face-to-face  manner. 

Finally,  the  bold-face  letter  "H"  is  used  to  designate  handoffs  in  the  process,  as  work  is  passed 
from  people  in  one  organizational  role  to  another.  For  instance,  the  first  such  handoff  occurs  between  the 
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SOW-preparation  (node  "A")  and  draft-RFP  (node  "B")  activities.  This  handoff  reflects  the  fact  that  SOWs 
are  generally  developed  by  technical  people  (e.g.,  design  engineers,  manufacturing  engineers,  logistics 
engineers;  denoted  by  the  label  "T"),  whereas  RFPs  receive  the  greater  attention  from  business  people  (e.g., 
contract  specialists,  price/cost  analysts,  estimators;  denoted  by  the  label  "B").  Thus,  we  mark  a  handoff 
from  one  organizational  role  to  another.  A  similar  handoff  occurs  between  the  next  activities  (i.e.,  nodes 
"B"  and  "C"),  as  the  business  people  responsible  for  drafting  the  RFP  are  generally  much  lower  in  the 
organizational  hierarchies  than  the  managers  who  develop  the  alpha  contracting  plan  (e.g.,  program 
managers  and  deputies;  denoted  by  the  label  "M").  Thus,  we  mark  another  handoff  from  one  organizational 
role  to  another.  Indeed,  the  model  in  Figure  10  depicts  one  such  handoff  at  every  step  of  the  process  flow.  It 
is  important  to  note,  however,  that  this  alpha  contracting  process  involves  substantially  fewer  such  handoffs 
than  its  baseline  counterpart  that  we  noted  above  as  the  "traditional"  (i.e.,  pre-alpha)  contracting  process. 

Process  Measurement  and  Diagnosis 

Process  measurements  and  diagnoses  obtained  from  the  JSOW  model  represented  in  Figure  10  are 
summarized  in  Table  15.  Starting  at  the  top,  the  first  measurement  (7)  for  process  size  indicates  the  seven 
activities  (i.e.,  A  through  G)  for  the  process.  The  feedback  fraction  measurement  (0.29)  is  calculated  as  the 
ratio  of  feedback  loops  (2)  divided  by  process  size  (7)  and  represents  a  relatively  good  value  for  the 
contracting  process.  Before  the  alpha  contracting  innovation,  for  instance,  the  feedback  fraction  would 
easily  be  double  this  measured  value.  This  quantifies  some  of  the  considerable  progress  made  by  the  alpha 
contracting  innovation  over  the  "traditional"  contracting  process  baseline.  The  next  measurement  for 
parallelism  (1.17)  reveals  the  process  remains  quite  sequential,  however.  But  as  with  the  feedback 
measurement,  this  degree  of  parallelism  reflects  considerable  improvement  (17%)  over  the  baseline  process. 
Thus,  we  see  even  the  alpha  contracting  process  still  suffers  from  sequential  process  flows,  which  has  cycle 
time  implications. 

Continuing  down  the  table,  the  IT-Support  fraction  (0.71)  reveals  relatively  good  usage  of  IT  in 
the  process,  as  five  of  the  seven  activities  involve  use  of  a  word  processor  ("WP").  That  is  not  to  say 
additional  IT  could  not  be  employed,  but  the  process  is  clearly  not  deficient  in  this  regard.  In  contrast,  the 
measured  values  of  IT-Communication  (0.00)  and  IT-Automation  (0.00)  reflect  theoretical  minima  for  the 
corresponding  metrics.  This  quantifies  the  fact  that  IT  is  not  employed  for  communication  and  none  of  the 
process  steps  is  automated.  Thus,  the  process  suffers  potentially  serious  pathologies  in  terms  of  being  paper- 
based  and  labor-intensive,  which  have  both  cost  and  cycle  time  implications.  Finally,  the  measured  handoffs 
fraction  (1.00)  indicates  each  of  the  seven  process  steps  is  accompanied  by  a  handoff  between  people 
performing  different  organizational  roles.  Such  handoffs  are  associated  with  the  pathology  of  process 
friction,  which  can  have  severe  implications  in  teims  of  cycle  time.  Thus,  even  with  the  streamlining 


enabled  through  the  alpha  contracting  innovation,  the  JSOW  contracting  process  still  suffers  from  a  number 
of  serious  pathologies.  Therefore  it  follows  that  even  the  alpha  contracting  process  offers  potential  for 
further  innovation. 


Table  15  JSOW  Baseline  Configuration  Measurements  and  Diagnoses 


Configuration  Measure 

Value 

Diagnosis 

Process  Size 

7 

Feedback  fraction 

0.29 

Parallelism 

1.17 

Sequential  process  flows 

IT-Support  fraction 

0.71 

IT-Communication  fraction 

0.00* 

Paper-based  process 

IT-Automation  fraction 

0.00* 

Labor-intensive  process 

Handoffs  fraction 

1.00 

Process  friction 

*  denotes  theoretical  extremum  for  a  measure 


Process  Redesign 

Based  on  the  process  measurements  above,  a  number  of  redesign  transformations  can  be  identified  to 
further  enhance  the  JSOW  alpha  contracting  process.  In  this  section,  we  explicitly  examine  three  classes  of 
redesigns:  1)  de-linearization,  2)  IT  and  3)  frictionless.  It  is  important  to  note  these  classes  are  not  mutually 
exclusive;  that  is,  one  can  combine  de-linearization  with  IT  and  frictionless  redesigns.  Here,  we  present 
them  separately  for  clarity  and  leave  such  combination  as  a  practical  exercise  for  the  reader  in  his  or  her 
own  organization. 

De-linearization  redesign.  Looking  first  at  the  parallelism  measurement,  we  ask  whether  any  of  the  process 
activities  could  be  performed  concurrently.  The  usual  technique  for  making  this  assessment  is  to  determine 
whether  inputs  and  outputs  are  mutually  exclusive;  that  is,  one  looks  at  the  inputs  to  a  particular  process  and 
makes  a  determination  whether  outputs  from  the  predecessors  are  required  for  its  performance.  If  so,  the 
activities  must  be  performed  in  series.  But  if  not,  this  presents  an  opportunity  to  perform  them  in  parallel 
(i.e.,  de-linearize).  For  instance,  output  from  the  first  process  activity — SOW-preparation  in  node  "A" — 
generally  includes  a  statement  of  work.  So  one  asks  whether  the  SOW  is  required  for  the  next  activity — 
draft-RFP  in  node  "B."  In  some  respects,  the  answer  is  yes,  in  that  a  completed  RFP  specifies  the  work  to  be 
performed. 

But  one  could  argue  a  substantial  amount  of  RFP  work  (e.g.,  selecting  contract  type,  identifying 
clauses  for  incorporation,  drafting  inspection,  acceptance,  packaging  and  other  requirements)  could  at  least 
begin  while  the  SOW  was  being  developed.  In  other  words,  many  aspects  of  RFP  preparation  do  not  depend 
on  the  SOW.  Thus,  we  may  be  able  to  increase  alpha  contracting  process  parallelism  by  at  least  starting  the 
draft-RFP  process  activity  before  the  SOW  has  been  completed,  possibly  deferring  integration  of  the  two 
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until  the  planning  step  (node  "C").  Though  again,  clearly,  the  RFP  activities  cannot  be  completed  without 
having  the  procurement  requirements  (i.e.,  the  SOW). 


Figure  11  JSOW  De-linearization  Process  Model 


Table  16  JSOW  Comparative  Process  Measurements 


Configuration  Measure 

Baseline 

Value 

Redesign 

Value 

Process  Size 

7 

7 

Feedback  fraction 

0.29 

0.29 

Parallelism 

1.17 

1.40 

IT-Support  fraction 

0.71 

0.71 

IT-Communication  fraction 

0.00* 

0.00* 

IT-Automation  fraction 

0.00* 

0.00* 

Handoffs  fraction 

1.00 

1.00 

*  denotes  theoretical  extremum  for  a  measure 


This  partial  process  redesign  is  delineated  in  Figure  1 1  with  corresponding  measurements 
summarized  in  Table  16  for  comparison  with  the  baseline  alpha  contracting  process.  Notice  process  length 
would  decrease  to  5  in  this  de-linearized  redesign.  This  effect  can  be  observed  in  the  figure  through  parallel 
performance  of  nodes  "A"  and  "B"  and  is  quantified  by  the  parallelism  measurement,  the  latter  of  which 
increases  to  1 .40  through  the  redesign.  Shortening  process  length  in  this  fashion  should  have  a  direct  impact 
on  decreasing  process  cycle  time.  Similar  analysis  of  other  process  activities  may  reveal  additional 
opportunities  to  increase  process  concurrency  through  partial  de-linearization.  Again,  the  customary 
technique  involves  examining  inputs  to  and  outputs  from  successive  process  activities  to  determine  whether 
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serial  activities  are  sequentially  dependent  (i.e.,  must  be  performed  serially)  or  not  (i.e.,  can  be  performed 
concurrently). 

IT  redesigns.  The  IT-oriented  pathologies  can  also  be  addressed  through  process  redesign,  particularly 
paper-based  process  communications.  Since  process  documents  are  prepared  using  a  word  processor  now, 
there  is  little  reason  why  they  cannot  be  transmitted  via  computer  (e.g.,  as  e-mail  attachments)  between  the 
various  steps  of  the  process.  Even  if  paper  copies  are  printed  within  each  process  activity  (e.g.,  used  by  the 
alpha  contracting  teams),  cycle  time  may  be  reduced  through  electronic  transmission  between  process 
activities  (e.g.,  SOW  preparation  and  draft  RFP).  But  this  raises  the  issue  of  control.  One  positive  aspect  of 
paper-based  communication  is  that  copying  one  original  document  helps  ensure  every  recipient  receives  the 
same  information. 

Alternatively,  without  control  over  electronic  document  transmission,  an  engineer,  say,  could 
modify  the  SOW  and  send  it  to  his  or  her  technical  counterpart  without  notifying  the  contracts  and  pricing 
people.  Similarly,  a  program  manager  could  change  one  of  the  scheduling  assumptions  without  notifying  the 
engineers.  Many  similar  examples  can  be  developed.  Notwithstanding  available  control  techniques,  such  as 
issuing  written  policy  statements  against  unauthorized  changes  and  using  change-tracking  features  of 
modem  word  processors,  document  control  remains  an  important  consideration  whenever  electronic 
communications  are  envisioned. 

One  approach  is  to  centralize  electronic  distribution,  and  the  Web  enables  such  centralization 
without  compromising  decentralized  document  production  (e.g.,  by  each  alpha  contracting  team  member). 
Through  such  an  approach,  each  team  member  could  generate  documents  and  make  changes  as  in  the 
process  above,  but  such  documents  and  changes  would  only  be  disseminated  from  a  single  Web  server.  As 
in  a  technical  configuration  management  environment,  for  example,  individual  engineers,  program 
managers  or  contracting  professionals  could  be  required  to  ’’check-out"  each  document  from  a  central 
repository  on  the  Web  server.  While  changes  are  being  made  by  this  individual,  the  checked-out  document 
would  have  read-only  access  to  other  individuals  until  the  changes  are  complete.  And  here  is  where  change 
tracking  could  be  used  most  effectively  to  ensure  accountability  for  changes  to  a  document.  This  redesign 
can  effect  electronic  communication  between  every  process  activity,  which  offers  excellent  potential  for 
reducing  cycle  time  and  complements  the  existing  use  of  IT  (e.g.,  word  processors)  in  the  process.  Indeed, 
the  Web  is  used  for  contracting  activities  such  as  market  research  today,  so  the  necessary  infrastructure  and 
experience  is  likely  to  already  be  in  place  in  many  contracting  offices. 


55 


Figure  12  JSOW  Web-centric  Process  Model 

This  Web-centric  means  of  enabling  redesign  through  electronic  communication  is  delineated  in 
Figure  12  with  corresponding  measurements  summarized  in  Table  17  for  comparison  with  the  baseline 
alpha  contracting  process.  Notice  IT-Communication  fraction  would  increase  to  0.71  in  this  Web-enabled 
redesign.  This  represents  dramatic  improvement  over  the  process  baseline,  the  measurement  for  which 
(0.00)  represents  negligible  electronic  communication  and  a  theoretical  minimum  for  this  measure.  This 
effect  can  be  observed  in  the  figure  through  the  ’’Web"  attributes  associated  with  communications. 
Implementing  electronic  communications  in  this  fashion  should  have  a  direct  impact  on  decreasing  process 
cycle  time.  Similar  analysis  of  other  process  activities  may  reveal  additional  opportunities  to  increase 
electronic  communication  through  complementary  technologies. 


Table  17  JSOW  Comparative  Process  Measurements 


Configuration  Measure 

Baseline 

Value 

Redesign 

Value 

Process  Size 

7 

7 

Feedback  fraction 

0.29 

0.29 

Parallelism 

1.17 

1.17 

IT-Support  fraction 

0.71 

0.71 

IT-Communication  fraction 

0.00* 

0.71 

IT- Automation  fraction 

0.00* 

0.00* 

Handoffs  fraction 

1.00 

1.00 

*  denotes  theoretical  extremum  for  a  measure 
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Regarding  the  negligible  IT-Automation,  this  pathology  is  more  difficult  to  address  than  its  IT- 
Communication  counterpart  above,  for  much  of  the  required  information  technology  has  yet  to  emerge  from 
the  research  laboratory.  Notwithstanding  a  number  of  legacy  systems  (e.g.,  APADE,  SACCONS)  that  offer 
some  automated  support  for  contractual  documentation,  such  systems  automate  only  the  most  basic  aspect 
of  document  composition,  and  many  feel  they  inhibit  the  process  as  much  as  they  facilitate  it  (e.g.,  see 
McCarthy  1998,  Nissen  1996b).  Even  the  Standard  Procurement  System  (SPS),  which  represents  a  marked 
improvement  through  workflow  functionality  and  EDI  interface,  automates  only  the  most  routine  and 
perfunctory  aspects  of  procurement  (e.g.,  clause  selection,  document  composition,  forms  routing).  Indeed,  if 
we  define  automation  as  the  performance  of  work  activities  without  a  person  in  the  loop,  it  is  more  accurate 
to  describe  SPS  in  terms  of  IT-Support  than  IT-Automation,  for  it  automates  very  little.  Still, 
implementation  of  SPS  in  the  JSOW  alpha  contracting  process  would  serve  to  further  streamline  and 
enhance  it.  And  given  plans  for  DoD-wide  SPS  implementation,  it  is  only  a  matter  of  time  before  the  JSOW 
process  is  streamlined  in  this  manner. 


Figure  13  JSOW  SPS  Process  Model 

This  SPS-based  redesign  is  delineated  in  Figure  13  with  corresponding  measurements  summarized 
in  Table  18  for  comparison  with  the  baseline  alpha  contracting  process.  Notice  IT-Support  fraction  would 
increase  to  1.00  in  this  SPS-based  redesign.  This  represents  modest  improvement  over  the  process  baseline. 
This  effect  can  be  observed  in  the  figure  through  the  "SPS"  attribute  associated  with  the  draft-RFP  and 
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proposal  activities  (nodes  "B"  and  "D").  As  SPS  capabilities  expand  to  support  more  of  the  contracting 
process  life  cycle,  opportunities  to  further  improve  the  IT-Support  fraction  may  present  themselves.  Notice 
SPS  also  supports  electronic  communication  of  the  draft-RFP  activity  (node  B)  and  increases  the  IT- 
Communication  measurement  slightly  (0.14). 


Table  18  JSOW  Comparative  Process  Measurements 


Configuration  Measure 

Baseline 

Value 

Redesign 

Value 

Process  Size 

7 

7 

Feedback  fraction 

0.29 

0.29 

Parallelism 

1.17 

1.17 

IT-Support  fraction 

0.71 

1.00 

IT-Communication  fraction 

0.00* 

0.14 

IT- Automation  fraction 

0.00* 

0.00* 

Handoffs  fraction 

1.00 

1.00 

*  denotes  theoretical  extremum  for  a  measure 


Alternatively,  some  very  promising  information  technology  is  beginning  to  emerge  from  the 
research  laboratory  (e.g.,  see  Nissen  1997)  to  automate  a  number  of  important,  time-consuming 
procurement  activities.  One  class  involves  the  use  of  knowledge-based  systems  (KBS)  to  perform  key 
contracting  activities  such  as  RFP  composition,  contracting-officer  review,  proposal  analysis  and  others. 
Building  on  expert  systems  expertise,  such  tools  offer  potential  to  eliminate  a  number  of  human  steps  from 
the  contracting  process,  which  has  positive  performance  implications  both  in  terms  of  cost  and  cycle  time. 

In  fact,  contracting  KBS  have  now  emerged  from  the  laboratory  (e.g.,  CESA:  Contracting  officer’s  technical 
representative  Expert  System  Aid;  see  Liebowitz  1999). 

Although  such  systems  are  unlikely  to  ever  replace  all  the  people  in  the  process,  the  possibility  of 
having  some  80%  of  tasks  performed  automatically  (e.g.,  using  an  ”80/20"  rule)  is  exciting.  For  instance,  a 
KBS  could  be  used  to  process  some  80%  or  so  of  contracting  tasks  that  are  routine  and  perfunctory  (e.g., 
mandatory  clause  selection).  With  this,  contracting  professionals  (i.e.,  people)  could  then  be  freed  to  use 
their  expertise  for  more  novel,  complex  and  demanding  issues  and  problems.  And  if  such  technology  can  be 
effectively  integrated  with  the  Web  and  workflow  systems  such  as  SPS,  the  performance  implications  are 
huge.  As  noted  recently,  this  technology  represents  the  next  generation  of  capability  for  SPS  (see  Karty  and 
Nissen  1999). 
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Figure  14  JSOW  KBS  Process  Model 

This  KBS-based  redesign  is  delineated  in  Figure  14  with  corresponding  measurements  summarized 
in  Table  19  for  comparison  with  the  baseline  alpha  contracting  process.  Notice  IT- Automation  fraction 
would  increase  to  0.29  in  this  KBS-enabled  redesign.  This  represents  dramatic  improvement  over  the 
process  baseline,  the  measurement  for  which  (0.00)  represents  negligible  process  automation  and  a 
theoretical  minimum  for  this  measure.  This  effect  can  be  observed  in  the  figure  through  the  "KBS" 
attributes  associated  with  automation.  Automating  activities  in  this  fashion  should  have  a  direct  impact  on 
decreasing  both  process  cost  and  cycle  time.  However,  much  greater  leverage  could  be  achieved  through 
this  redesign  when  it  is  integrated  with  other  IT-based  transformations.  As  noted  above,  this  leverage  is 
particularly  great  through  integration  with  Web  communications  and  SPS. 


Table  19  JSOW  Comparative  Process  Measurements 


Configuration  Measure 

Baseline 

Value 

Redesign 

Value 

Process  Size 

7 

7 

Feedback  fraction 

0.29 

0.29 

Parallelism 

1.17 

1.17 

IT-Support  fraction 

0.71 

0.71 

IT-Communication  fraction 

0.00* 

0.00* 

IT-Automation  fraction 

0.00* 

0.29 

Handoffs  fraction 

1.00 

1.00 

*  denotes  theoretical  extremum  for  a  measure 


59 


Another,  more  advanced  class  of  promising  information  technology  beginning  to  emerge  from  the 
research  laboratory  (e.g.,  see  Nissen  1999)  involves  the  use  of  intelligent  agents  to  represent  buyers  and 
sellers  in  transactions.  Also  involving  artificial  intelligence,  intelligent  agents  have  been  developed  to 
capture  enterprise  work  rules  and  user  preferences  to  automatically  perform  a  number  of  procurement 
activities  (e.g.,  market  research,  RFP  preparation  and  transmission,  proposal  preparation  and  transmission, 
proposal  analysis  and  source  selection,  ordering,  payment)  without  human  intervention.  In  a  nutshell,  agents 
representing  the  Government  program  office  and  contractor  can  perform  most  of  the  baseline  alpha 
contracting  process  activities  delineated  in  Figures  9  and  10  on  behalf  of  their  principals.  This  has 
enormous  performance  implications  in  terms  of  cost  and  cycle  time.  But  more  so  than  above,  such  systems 
are  unlikely  to  ever  replace  all  the  people  in  the  process,  and  intelligent  agent  technology  is  less  mature  than 
its  KBS  counterpart  above.  Thus,  it  is  not  yet  ready  for  emergence  from  the  laboratory.  Nonetheless,  as 
noted  recently,  this  technology  represents  the  generation  after  next  of  capability  for  SPS  (see  Karty  and 
Nissen  1999). 


Figure  15  JSOW  Agent  Process  Model 


This  agent-based  redesign  is  delineated  in  Figure  15  with  corresponding  measurements 
summarized  in  Table  20  for  comparison  with  the  baseline  alpha  contracting  process.  For  conservatism,  we 
continue  to  include  activities  for  the  business  clearances  (node  ME")  and  negotiation  targets  (node  "F"),  and 
we  do  not  show  the  agents  conducting  negotiations  (node  "G").  Notwithstanding  progress  being  made  with 
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respect  to  agent-based  negotiation,  particularly  for  large  contracts  such  as  the  JSOW,  agents  are  unlikely  to 
conduct  negotiations  in  the  near  future.  If  not  for  these  conservative  assumptions,  the  process  depicted  in 
Figure  15  would  have  only  two  steps:  SOW-preparation  (node  "A")  and  one  consolidated  activity  reflecting 
agent-based  tasks. 

Returning  to  the  more- conservative  process  redesign  delineated  in  Figure  15,  notice  a  number  of 
process  changes.  First,  process  size  drops  to  5  activities  from  7.  This  reflects  agent  consolidation  of 
activities  that  were  performed  separately  by  people  (i.e.,  "B"  and  "D").  Parallelism  also  increases  slightly, 
due  to  this  consolidation.  And  the  agent  approach  obviates  the  feedback  loops,  bringing  the  feedback 
fraction  effectively  to  zero.  All  three  of  the  IT  fractions  are  affected  through  this  dramatic  change,  with  IT- 
Communication  and  IT-Automation  both  showing  marked  gains. 


Table  20  JSOW  Comparative  Process  Measurements 


Configuration  Measure 

Baseline 

Value 

Redesign 

Value 

Process  Size 

7 

5 

Feedback  fraction 

0.29 

0.00* 

Parallelism 

1.17 

1.20 

IT-Support  fraction 

0.71 

0.60 

IT-Communication  fraction 

0.00* 

0.20 

IT-Automation  fraction 

0.00* 

0.20 

Handoffs  fraction 

1.00 

1.00 

*  denotes  theoretical  extremum  for  a  measure 


This  represents  dramatic  improvement  over  the  process  baseline,  the  measurements  for  which 
(0.00)  represent  negligible  electronic  communication  or  process  automation  and  theoretical  minima  for 
these  measures.  These  effects  can  be  observed  in  the  figure  through  the  ’’EC”  and  "LA”  attributes  associated 
with  agent-based  communication  and  automation,  respectively.  Automating  activities  in  this  fashion  should 
have  a  direct  impact  on  decreasing  both  process  cost  and  cycle  time.  However,  as  with  the  KBS  redesign 
noted  above,  much  greater  leverage  could  be  achieved  through  this  agent  redesign  when  it  is  integrated  with 
other  IT-based  transformations.  This  leverage  is  particularly  great  through  integration  with  Web 
communications  and  SPS. 

Frictionless  redesigns.  The  final  alpha  contracting  pathology  to  be  addressed  is  the  substantial  friction 
stemming  from  numerous  handoffs  in  the  process.  From  above,  handoffs  derive  from  work  passing  between 
people  performing  different  roles  in  the  process  flow.  A  widely  used  approach  to  reducing  handoffs  in  a 
process  is  to  enlarge  the  job  breadth  of  process  participants.  The  most  extreme  example  of  this  is  through  a 
case  manager,  in  which  a  single  individual  performs  all  process  steps.  This  is  probably  unrealistic  in  the 
case  of  procurement  and  contracting,  but  even  two  organizational  roles  that  can  be  spanned  through  job 
enlargement  leads  to  a  corresponding  reduction  in  process  friction,  with  its  attendant  cycle  time 
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implications.  Thus,  we  would  examine  each  of  the  process  activities  to  assess  whether  it  could  be  performed 
without  use  of  a  specialist.  For  instance,  the  first  two  process  activities — SOW-preparation  and  draft-RFP — 
are  currently  performed  by  people  with  different  organizational  roles:  technical  people  and  business 
workers.  We  would  ask  whether  people  from  one  role  or  the  other  could  perform  both  activities;  that  is, 
could  engineers  and  other  technical  people  perform  the  business  tasks  associated  with  RFP  preparation,  or 
could  contract  specialists  and  other  business  people  perform  the  technical  tasks  associated  with  SOW 
development?  In  light  of  current  technology  available  to  support  the  process,  and  the  considerable 
education,  training  and  experience  required  for  technical  and  business  people  to  become  proficient  in  their 
respective  areas  of  expertise,  this  is  unlikely  to  be  feasible  at  present. 


© 

-  SOW-negot 

-all 

-IA 

-EC 

-IA 


Figure  16  JSOW  Frictionless  Process  Model 

However,  the  knowledge  systems  and  intelligent  agents  discussed  above  may  offer  potential  in  this 
regard.  For  example,  a  knowledge  system  capable  of  composing  simple  RFPs  could  be  employed  by  the 
technical  people  to  perform  this  activity.  This  is  far  more  likely  and  promising  than  trying  to  invent  some 
technology  that  would  enable  contracts  people  to  prepare  statements  of  work.  And  as  noted  above,  such 
systems  are  now  out  of  the  research  laboratory  and  may  represent  the  next  generation  of  capability  for  SPS. 
Even  more  impressive  are  the  intelligent  agents.  With  suitably-developed  technology,  these  same  technical 
people  could  employ  agents  to  perform  all  the  activities  required  for  contracting  in  a  relatively  simple 
procurement.  Although  this  is  unlikely  for  a  large,  complex  procurement  such  as  the  JSOW,  the  promise  of 
agent  technology  for  the  huge  volume  of  simplified  procurements  is  gargantuan.  And  as  noted  above,  such 
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systems  are  now  being  demonstrated  in  the  research  laboratory  and  may  represent  the  generation  after  next 
of  capability  for  SPS. 


Table  21  JSOW  Comparative  Process  Measurements 


Configuration  Measure 

Baseline 

Value 

Redesign 

Value 

Process  Size 

7 

1 

Feedback  fraction 

0.29 

0.00* 

Parallelism 

1.17 

1.00 

IT-Support  fraction 

0.71 

1.00 

IT-Communication  fraction 

0.00* 

1.00 

IT- Automation  fraction 

0.00* 

1.00 

Handoffs  fraction 

1.00 

0.00* 

*  denotes  theoretical  extremum  for  a  measure 


This  frictionless  redesign  is  delineated  in  Figure  16  with  corresponding  measurements  summarized  in  Table 
21  for  comparison  with  the  baseline  alpha  contracting  process.  Here,  we  show  intelligent  agents  performing 
all  the  procurement  steps  from  SOW-preparation  (formerly  node  "A")  through  negotiation  (formerly  node 
"G").  Notice  the  dramatic  effect  on  all  process  measures.  Although  this  process  redesign  is  obviously  very 
extreme  and  futuristic,  it  is  informative  to  view  such  a  redesign  in  terms  of  a  vision  for  the  procurement 
process  of  the  future. 

Metaphorically  speaking,  if  man  never  dreamed  about  flying,  he  probably  would  never  have  set 
about  to  build  airplanes.  If  we  never  develop  future  process  visions,  researchers  are  unlikely  to  pursue  the 
technologies  required  to  bring  them  about.  Moreover,  futuristic  as  this  process  vision  may  appear  at  first, 
many  of  the  requisite  technologies  (e.g.,  Web  communications,  knowledge-based  systems,  intelligent 
agents)  are  available  today .  But  until  the  contracting  organization  is  ready  for  such  technologies — that  is, 
ready  to  pursue  such  a  radical  process  vision — such  technological  innovation  is  unlikely  to  become  manifest 
in  contracting  practice. 
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CHAPTER  4  SUMMARY 


The  JSOW  process  is  useful  to  demonstrate  how  further  innovation  is  possible  with  an  alpha  contracting 
process.  Using  the  notation  and  redesign  approach  introduced  in  Chapter  3,  the  JSOW  alpha  contracting 
process  is  modeled  for  redesign  analysis,  measured  to  diagnose  pathologies  and  redesigned  to  further 
improve  performance.  Measurements  reveal  a  number  of  serious  pathologies,  even  with  the  innovative, 
alpha  contracting  process  used  as  a  baseline  for  analysis.  These  pathologies  include  sequential  process 
flows  and  a  paper-based,  labor  intensive  process  with  considerable  friction.  Together,  such  process 
pathologies  have  adverse  implications  in  terms  of  both  cost  and  cycle  time. 

Three  classes  of  redesigns  are  examined:  1)  de-linearize,  2)  IT  and  3)  ffictionless.  We  examine  and 
discuss  each  redesign  individually.  But  it  is  important  to  note  the  redesigns  are  in  no  way  mutually 
exclusive,  and  even  greater  performance  improvements  may  be  possible  by  combining  them.  The  de- 
linearize  redesign  is  applied  through  performance  of  two  or  more  process  activities  in  parallel,  as  opposed 
to  serially.  To  demonstrate  the  technique,  we  depict  partial  performance  of  two  parallel  activities — SOW 
preparation  and  draft  RFP — in  this  fashion.  De-linearization  offers  good  potential  in  terms  of  cycle  time 
reduction. 

Four  IT-driven  redesigns  are  examined  above.  The  first  two  redesigns — Web-based 
communications  and  SPS  implementation — are  enabled  through  information  technology  that  is  readily 
available  today.  The  use  of  Web-based,  electronic  communications  is  particularly  noteworthy  for  enabling 
cycle  time  reduction  without  sacrificing  control  over  contractual  documents.  The  second  two  redesigns — 
through  knowledge-based  systems  and  intelligent  agents — are  based  on  information  technologies  that 
remain  closer  to  the  laboratory  than  the  operational  contracting  office.  But  they  offer  enormous  potential  in 
terms  of  dramatic  cost  and  cycle  time  reduction. 

The  ffictionless  redesign  involves  elimination  of  handoffs  between  process  activities  and  requires 
IT  support.  We  examine  the  use  of  intelligent  agent  technology  to  collapse  the  entire  procurement  process 
into  a  single,  automated  activity.  Although  very  radical,  this  ffictionless  process  redesign  serves  to  present  a 
vision  of  the  future  of  procurement.  Such  a  vision  is  important  to  guide  research  and  represents  a  goal 
toward  which  contract  managers  should  strive.  But  despite  this  focus  on  the  future,  the  technology  required 
to  enable  the  corresponding  process  vision  is  less  than  a  half  decade  away  at  the  time  of  this  writing. 
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CHAPTER  4  QUESTIONS 


1 .  Which  process  pathologies  affect  even  the  innovative,  alpha  contracting  process? 

2.  What  are  the  performance  implications  of  these  pathologies? 

3.  Which  information  technologies  offer  potential  for  performance  improvement  through  process 
redesign? 

4.  Which  non-IT  transformations  offer  potential  for  performance  improvement  through  process  redesign? 
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CHAPTER  4  ANSWERS 


1 .  Alpha  contracting  process  pathologies  include  sequential  process  flows  and  a  paper-based,  labor 
intensive  process  with  considerable  friction. 

2.  Together,  such  process  pathologies  have  adverse  implications  in  terms  of  both  cost  and  cycle  time. 

3.  Web-based  electronic  communications,  the  Standard  Procurement  System,  knowledge-based  systems 
and  intelligent  agents  represent  information  technologies  with  good  potential  for  process  performance 
through  redesign. 

4.  Process  de-linearization  and  frictionless  redesigns  do  not  necessarily  require  IT  for  performance 
improvement.  However,  in  the  example  above,  frictionless  redesign  is  seen  to  benefit  from  IT  support. 
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1  It  is  important  for  the  experienced  reader  to  note  the  intent  here  is  to  capture  the  key,  high-level  activities 
and  sequencing  associated  with  the  contracting  process  in  general.  Notice  too  that  many  process  steps  (e.g., 
DCAA  audit,  Independent  Government  Analysis,  etc.)  have  purposefully  been  omitted  from  the  diagram  to 
reduce  clutter  and  focus  the  discussion.  The  point  is  to  abstract  away  from  the  myriad  details  that  do  not 
contribute  to  comparison. 

1  See  Rummler,  G.  and  Brache,  A.  Improving  Performance:  How  to  Manage  the  White  Space  on  the 
Organization  Chart.  San  Francisco,  CA:  Jossey-Bass  (1991). 

1  See  Amavas,  D.  and  Ruberry,  W.  Government  Contract  Guidebook  Second  Edition.  Washington,  DC: 
Federal  Publications  (1994);  Hearn,  E.  Federal  Acquisition  and  Contract  Management.  Los  Altos,  CA: 
Hearn  Associates  (1996);  Nissen,  M.  Knowledge-Based  Organizational  Process  Redesign:  Using  Process 
Flow  Measures  to  Transform  Procurement.  Doctoral  dissertation,  University  of  Southern  California  School 
of  Business  Administration  (1996);  and  Nissen,  M.  "Reengineering  the  RFP  Process  through  Knowledge- 
Based  Systems,"  Acquisition  Review  Quarterly  (Winter  1997). 

1  For  a  relatively  comprehensive  description  of  the  procurement  process,  the  reader  can  consult  the 
Contract  Specialist  Workbook  (see  http://www.gsa.gOv/staff/v/fai/workbooks/directions2.htm). 

1  For  example.  Change  Through  Ex-Change  Innovations  -  Alpha  Contracting  (March  1997),  pp.  65-78; 
Drewes,  R.  Early  CAS  Teaming  for  Acquisition  Success.  Defense  Logistics  Agency  Guidebook,  DCMC,  Ft. 
Belvoir,  VA  (1996);  personal  interviews  with  the  following:  PMA-201-  CAPT  Bert  Johnston,  CAPT  John 
Scheffler,  LCDR  Randy  Mahr,  Ms.  Pat  Hansley;  NAWCWD  -  Dr.  Lloyd  Smith,  Mr.  Tom  Lamb,  Ms. 
Leanna  Claunch;  Eglin  AFB  -  LTC  Steve  Whitten,  Ms.  Annette  Seda,  Mr.  Lane  Clark;  OC,  Inc.  -  Ms. 
Cheryl  Francis;  many  other  short  interviews,  interactions  and  opportunities  for  direct  observation  with 
government  personnel  and  contractor  employees  alike  (July- September  1997);  Meyer,  T.  “Alpha 
Contracting:  Applying  the  IPT  Approach  to  Contract  Negotiations,”  Army  RD&A  (Jan-Feb  1997);  and 
telephone  interview  with  Ms.  Connie  Tucker,  TACOM  Contracts  (August  1997). 

1  The  experienced  reader  will  note  that  joint  government-contractor  work  can  even  begin  prior  to  SOW 
development — for  example,  through  the  kinds  of  RFIs  and  presolicitation  conferences  conducted  in  the 
early  phases  of  AIWS  planning  and  development. 

1  The  employment  of  contemporary  collaborative  technologies  (e.g.,  shared  Internet  whiteboards,  video 
teleconferencing,  etc.)  would  appear  to  offer  promise  to  reduce  the  cost  and  difficulties  associated  with 
work  distributed  across  geographically-dispersed  sites.  This  is  the  essence  of  the  virtual  organization,  or  in 
DoD  parlance,  the  virtual  IPT. 
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